The forwarding delay and throughput of a proxy server play significant role in the overall network performance. It is widely known that the forwarding delay of proxy¡¦s application layer is much larger than that of lower layers. This is because for a general purpose operating system, the receiving or sending data in application layer needs to move data through the TCP/IP stack and also cross the user/kernel protection boundaries. TCP Splice can forward data directly in TCP layer without going up to the application layer. This can be achieved by modifying the packet headers of one TCP connection from the original server to the proxy so that the TCP connection can be seamlessly connected to another TCP connection from the proxy to the client. To maintain the caching ability of proxy, TCP Tap can duplicate packets before they are forwarded by TCP Splice. The duplicated packets are copied into a tap buffer, so the application layer can read data from the tap buffer. We fully utilize the original TCP receive queue as the tap buffer and allow application layer to read data as usual. We chose Linux as the platform for experiment. The TCP Splice and Tap are implemented as Linux modules. Finally, we develop an HTTP proxy to test and verify our implementation. It is shown that the performance of proxy in terms of lower forwarding delay, higher throughput, and increased CPU utilization, can be improved significantly.

Vorstellung des allg. Druckkonzeptes unter Linux und Hinweis auf verschiedene Spooling-Systeme, Print-Software und HOWTO

BSD Socket API for Simulator is a project to run untouched Real World Application (RWA) binaries on the powerful modern general-purpose network simulators. BSD Socket API for Simulator is designed to eliminate most of the drawbacks of previous works. It is simulator independence, so it can make use of the powerful functionality and versatile tools provided by modern general-purpose simulators such as NS-2. It is fully compatible with BSD Socket API, so RWA can be run on it without re-linking and re-compiling. It is transparent to the RWA, so RWAs are run on BSD Socket API for Simulator as they are on normal operating systems. BSD Socket API for Simulator is built on the concept of message redirecting. It has two critical parts: shared library and customized simulator application. The shared library is loaded into the address space of RWA. On one hand, messages sent by RWA are captured by the shared library and redirected to the customized simulator application. On the other hand, messages from simulator are redirected by the customized simulator application to the shared library. BSD Socket API for Simulator has been intensively tested. The test results show that it functions as expected and it has an acceptable performance.

Vorstellung des allg. Druckkonzeptes unter Linux und Hinweis auf verschiedene Spooling-Systeme, Print-Software und HOWTO

Nos travaux abordent le problème de l'efficacité des techniques d'implémentation hautes performances du système de communication. Car si les principes généraux sont désormais bien connus, il n'en va pas toujours de même de leur application. Des résultats obtenus sur notre plate-forme expérimentale, nous tirons des conclusions quant aux aspects machine hôte, système, et protocoles. Pour l'aspect machine hôte nous montrons que la parallélisation des piles de communication est décevante et grandement limitée par les contentions d'origine système. Nous montrons également comment la technique ILP, destinée à limiter les accès mémoire, peut être intégrée à la méthode d'accès d'une pile TCP/IP. Les bénéfices de cette technique restent largement dépendants des conditions d'utilisation, de la nature de l'application, et des manipulations de données. Du point de vue système, l'étude de deux environnements d'exécution de protocoles opposés, BSD et Streams, a permis d'identifier leurs faiblesses, et notamment pourquoi l'environnement Streams actuel n'est pas adapté aux hautes performances. Nous en déduisons un ensemble de principes qu'un environnement performant se doit de respecter. L'architecture de la pile de communication est essentielle. Nous montrons qu'une architecture démultiplexée, avec des chemins de données directs entre applications et drivers réseaux, permet un excellent support du contrôle de flux local et des mécanismes systèmes de QoS. En revanche, les implémentations de niveau utilisateur souffrent de nombreuses limitations. Elles sont cependant indispensables à certaines techniques. Du point de vue protocoles, nous montrons que la présence d'options dans les en-têtes de paquets n'est pas contraire à l'obtention de bonnes performances. A la notion trop rigide d'en-têtes de taille fixe nous substituons celle d'en-tétes de taille prédictible. Enfin, il ressort deux notions clés de ces travaux, la simplicité et la flexibilité, dont dépendent les performances et les fonctionnalités du système de communication.

<p>Denna rapport är resultatet av ett examensarbete, på 20 högskolepoäng, som har utförts på Scania CV AB, Tekniskt centrum, Södertälje. Examensarbetet behandlar Side Blind Spot Detection och har resulterat i ett prototypsystem som detekterar objekt i döda vinklarna på sidorna av en lastbil. Systemet är ett aktivt säkerhetssystem som syftar till att förhindra olyckor och ge ökad trafiksäkerhet på vägarna. </p><p>Examensarbetet har varit tvådelat för att uppnå detta mål. Denna rapport behandlar främst val av sensorteknik för att upptäcka objekt i de döda vinklarna på sidan av en lastbil. Den behandlar också hårdvara till användargränssnittet samt installation av användargränssnittet och sensorerna i en lastbil. Den andra delen av examensarbetet har bestått av utformning av användargränssnittet och programmering av systemet. Detta kan läsas i rapporten "Side Blind Spot Detection - System och användargränssnitt" författad av Jenny Hedenberg och Hanna Torell, Chalmers Tekniska högskola, 2005. </p><p>I rapporten har sex olika sensortekniker studerats och utvärderats. De sex sensorteknikerna är ultraljud, passiv IR, lidar (aktiv IR), kamera, IR kamera och radar. Resultatet av utvärderingen visade att radar är den mest lämpade sensortekniken för den här typen av applikationer och det är därför radar används som sensor i prototypsystemet. </p><p>Systemet har tre olika lägen beroende på hur mycket information föraren önskar få när ett objekt befinner sig i döda vinkeln vilket styrs av en systemknapp. Föraren får informationen från användargränssnittet som består av två LED- displayer som är placerade i dörrkarmarna på vardera sida. Förutom att visa varningarna visuellt i LED-displayen används också ljud vid varning. Resultatet blev som förväntat och visar de funktioner som användargränssnittet har på ett bra sätt. Vad gäller resultatet av hela prototypsystemet så visar det att radar är ett bra val för denna applikation för att den klarar av de krav som ställs. Tester av systemet visar dock att den införskaffade radarn har begränsningar som försvårar filtreringen. Detta leder till att systemet inte är helt tillförlitligt eftersom systemet ibland missar objekt och ibland felvarnar för objekt som inte finns eller för objekt som inte är relevanta.</p>

Denna rapport är resultatet av ett examensarbete, på 20 högskolepoäng, som har utförts på Scania CV AB, Tekniskt centrum, Södertälje. Examensarbetet behandlar Side Blind Spot Detection och har resulterat i ett prototypsystem som detekterar objekt i döda vinklarna på sidorna av en lastbil. Systemet är ett aktivt säkerhetssystem som syftar till att förhindra olyckor och ge ökad trafiksäkerhet på vägarna. Examensarbetet har varit tvådelat för att uppnå detta mål. Denna rapport behandlar främst val av sensorteknik för att upptäcka objekt i de döda vinklarna på sidan av en lastbil. Den behandlar också hårdvara till användargränssnittet samt installation av användargränssnittet och sensorerna i en lastbil. Den andra delen av examensarbetet har bestått av utformning av användargränssnittet och programmering av systemet. Detta kan läsas i rapporten "Side Blind Spot Detection - System och användargränssnitt" författad av Jenny Hedenberg och Hanna Torell, Chalmers Tekniska högskola, 2005. I rapporten har sex olika sensortekniker studerats och utvärderats. De sex sensorteknikerna är ultraljud, passiv IR, lidar (aktiv IR), kamera, IR kamera och radar. Resultatet av utvärderingen visade att radar är den mest lämpade sensortekniken för den här typen av applikationer och det är därför radar används som sensor i prototypsystemet. Systemet har tre olika lägen beroende på hur mycket information föraren önskar få när ett objekt befinner sig i döda vinkeln vilket styrs av en systemknapp. Föraren får informationen från användargränssnittet som består av två LED- displayer som är placerade i dörrkarmarna på vardera sida. Förutom att visa varningarna visuellt i LED-displayen används också ljud vid varning. Resultatet blev som förväntat och visar de funktioner som användargränssnittet har på ett bra sätt. Vad gäller resultatet av hela prototypsystemet så visar det att radar är ett bra val för denna applikation för att den klarar av de krav som ställs. Tester av systemet visar dock att den införskaffade radarn har begränsningar som försvårar filtreringen. Detta leder till att systemet inte är helt tillförlitligt eftersom systemet ibland missar objekt och ibland felvarnar för objekt som inte finns eller för objekt som inte är relevanta.

Existen numerosos trabajos que estudian o tratan la realización software de los protocolos de comunicaciones para el acceso a la Internet-TCP/IP. Sin embargo, no conocemos ninguno que modele de forma general y precisa la ejecución de este software.La presente tesis aporta una caracterización detallada de la ejecución de la realización software de los mencionados protocolos sobre un computador personal y bajo un sistema operativo UNIX. Esta caracterización muestra cómo varía el rendimiento del sistema en función de la velocidad de operación de la CPU, las características del subsistema de memoria, el tamaño de los paquetes y otras variables de importancia para la remisión, autenticación y cifrado de paquetes IP.En otros trabajos se proponen adecuaciones o extensiones a la realización software de los mencionados protocolos que permiten que un software router provea de comunicaciones con diversos niveles asegurados de calidad mediante el uso de mecanismos de planificación para la unidad central de procesamiento. Sin embargo, en dichos trabajos no se contempla la planificación del uso del bus de entrada/salida. Los resultados derivados de nuestro modelo demuestran que, para sistemas que usan CPUs con frecuencias de reloj superiores a 1 GHz, la planificación conjunta de la CPU y el bus de entrada salida es indispensable para la provisión de comunicaciones con diversos niveles asegurados de calidad. Dichas frecuencias de reloj son comunes en los sistemas comerciales actuales, por lo que consideramos que es un problema de gran interés. En la tesis proponemos un mecanismo que consigue garantías de utilización del bus de entrada/salida mediante la modificación de los drivers de los interfaces de red. / Three are the main contributions of this work. In no particular order:" A detailed performance study of the software implementation of the TCP/IP protocols suite, when executed as part of the kernel of a BSD operating system over generic PC hardware." A validated queuing network model of the studied system, solved by computer simulation." An I/O bus utilization guard mechanism for improving the performance of software routers supporting QoS mechanisms and built upon PC hardware and software.This document presents our experiences building a performance model of a PC-based software router. The resulting model is an open multiclass priority network of queues that we solved by simulation. While the model is not particularly novel from the system modeling point of view, in our opinion, it is an interesting result to show that such a model can estimate, with high accuracy, not just average performance-numbers but the complete probability distribution function of packet latency, allowing performance analysis at several levels of detail. The validity and accuracy of the multiclass model has been established by contrasting its packet latency predictions in both, time and probability spaces. Moreover, we introduced into the validation analysis the predictions of a router's single queue model. We did this for quantitatively assessing the advantages of the more complex multiclass model with respect to the simpler and widely used but not so accurate, as here shown, single queue model, under the considered scenario that the router's CPU is the system bottleneck and not the communications links. The single queue model was also solved by simulation.Besides, this document addresses the problem of resource sharing in PC-based software routers supporting QoS mechanisms. Others have put forward solutions that are focused on suitably distributing the workload of the CPU-see this chapter's section on "related work". However, the increase in CPU speed in relation to that of the I/O bus-as here shown-means attention must be paid to the effect the limitations imposed by this bus on the system's overall performance. We propose a mechanism that jointly controls both I/O bus and CPU operation. This mechanism involves changes to the operating system kernel code and assumes the existence of certain network interface card's functions, although it does not require changes to the PC hardware. A performance study is shown that provides insight into the problem and helps to evaluate both the effectiveness of our approach, and several software router design trade-offs.

The thesis analyzes the network traffic on a router with open source firmware. First is chosen a software platform, based on compatibility with available equipment. Then are assessed properties necessary for the development of custom applications. Support for various programming languages provided by the SDK, development environment and the available modules and libraries, for working with network interface. Based on these factors is then chose method to realize the program. He is implemented on the OpenWRT firmware in C / C + + using network library pcap. These funds are used to capture and analyze network traffic. Obtained data are processed using methods of technical analysis, namely on the basis of moving averages, Stochastic oscillator and Bollinger bands. Based on results of these methods are generated and verified estimates of traffic. They are based on linear extrapolation, simplified for fixed intervals. The validity of each method is verified on base of the estimated value. Method is verified if estimated value of the traffic volume is in the Bollinger band, which is given by the standard deviation. Each method is tested several times in real traffic with different input parameters. Then is evaluated the influence of parameters on the error rate of methods. Individual methods are compared and evaluated based on the behavior in different scenarios and based on the average relative error.

This project deals with analysis of brute force attacks focused on breaking authentication of common services (especially ssh) of Linux and xBSD operating systems. It also examines real attacks, actual tools and ways of detection of theese attacks. Finaly there are designed new mechanisms of coordination and evaluation of distributed brute force attacks in distributed environment. These mechanisms are then implemented in distributed system called DBFAP.