Tamanoir implementation
We choose to use a portable language for the active networks users be able to define and write their own services. Thus, the Tamanoir execution environment running in user space is entirely written in Java which provides a great flexibility and is shipped with standard library. Unfortunately, the execution environment provided by the JVM (Java Virtual Machine) gives a very high level of abstraction, through which applications have some difficulties to obtain good performances. However, recent JVM releases (> 1.3.x) give excellent performance for the mainstream hardware architecture (i.e x86), mainly due to the improvements of Just-In-Time (JIT) compilation techniques.
The Execution Environment relies on a demultiplexer receiving active packets and redirecting these packets towards the adapted service in function of the service name in packets header. New services are plugged in the TAN dynamically.
Each service is written in Java and inherited from a generic class called Service, itself inherited from the Java Thread class. Thus, as shown Fig.1, each service is executed in a independent thread. For a given service, with TCP active streams, a thread service is dedicated for each stream while with UDP only one dedicated thread processes all streams. A given service can be applied on TCP or UDP active streams without change.
Fig.1: Each stream is processed in a dedicated thread.
In order to improve safety and security, some EE runs each service in a separated sand-boxes (JVM). This approach does not improve resources sharing on a node (if one process consumes all CPU resources, others processes will not be able to work correctly). Moreover a standard JVM footprint takes more than 100 MB of memory for each instance. Using a multi-thread approach and running one service in each thread rather than running as many instance of JVM as services greatly improves the memory consumption.
Encapsulated active streams
Fig.2: ANEP packets are encapsulated in TCP packet or UDP datagram.
Fig.3: Server (A) and client (B) access the active infrastructure (TANs) through proxyTAN.
Service deployment
Fig.4: Service deployment: (a) The active router on the left
checks its local service cache to process the multimedia
stream. If the service is not availabe it sends a service
request to the previous active router. (b) The active router on
the left send the active service to the router on the right
which finally install the service and process the stream.
Programming interface
TANet.java, recvANEPkt(), sendANEPkt(), recvANEPkt_next(), sendANEPkt_next(), sendPayload(), recvPayload()... (TODO)
The class TANet contains almost all the methods and constructors you need to build your own active services (deployed and ran on TANs) and applications (executed on clients system).
By reading standards services like FwdS (Forward service), PingS (ping service) and GzipS (compression service) shipped with the Tamanoir suite (in the services directory), you should be able to write your own first simple services in less than an hour. Next, by reading SendPackets and RecvPackets available in the tools directory you should be able to write your own client and server applications in few hours.
To understand the following explanations about the different send and receive methods, you must have the point of view of a service running on a given TAN. We consider an active stream of ANEP packets coming from the left, going through the TAN, and left the TAN from the right:
- recvANEPkt(): is used to receive ANEP packets coming from the left (i.e either from a server/client application or a previous TAN). Once received the packet can be processed by the service.
- recvANEPkt_next(): is used to receive ANEP packets coming from the right (i.e either from a server/client application or a previous TAN). Once received the packet can be processed by the service.
- sendANEPkt(): is used to send ANEP packets to the left.
- sendANEPkt_next(): is used to send ANEP packets to the right.
- sendPayload(): is used to send only the ANEP payload's (i.e without the ANEP header) to the left.
- sendPayload_next(): is used to send the ANEP payload's to the right.
- recvPayload_next(): is used to receive raw data from the right (not an ANEP packet). These data can be then ANEP encapsulated before being sent to the left.