Ejip
From JopWiki
Contents |
[edit] ejip - a realtime capable tcp/ip stack for jop
There are plenty of motivations to implement a tcp/ip stack on any computing plattform. Since jop was designed with realtime applications in mind, the stack should be able to be used by hard realtime applications even if the communication over the network itself is not realtime at all. E.g. a hard realtime application should be able to do its control task and log results over the network at a remote log server. The logging itself would be unreliable due to the non realtime behaviour of the underlying network, but it would not interfere with the realtime task.
The software architecture is somewhat based on the osi layers: e.g. all linklayers inherent from one parent class and use the same interface to communicate with the network layer (ip). Because of limited memory on JOP the whole stack (and partly even the applications) works with static allocated packet buffers, that are organised by and accessible through PacketPool. Every packet stores a fixed length array of integers as data buffer and some control information that is used while the packet travels up and down through the stack. Most protocols incorporate their own or sharing a RtThread for periodic work like processing one packet or timeout checks.
[edit] supported features
- multiple interfaces
- The stack supports multiple network interfaces with a routing table. This table is static (during the mission phase) at the moment, but could easily be enhanced to support dynamic route changes e.g. for failover. Every interface has its own MTU.
- linklayers
- Currently only SLIP is tested with the enhancements done in summer 2008, but PPP, ethernet+arp (through a CS8900 on the baseio extension board) should not be hard to get to work again at all.
- IP
- Sending raw ip packets
- Fragmentation and reassembly of too large IP packets
- IP options will be ignored, but the packets will be processed correctly otherwise.
- ICMP
- The stack provides an interface for sending pings and receiving the replies. It responds to external ping requests and sends correct error messages (e.g. port unreachable etc.).
- UDP
- Sending and receiving facilities for UDP packets have been implemented.
- TCP
- Server and client connections are supported.
- 3- (or 4-) way handshakes at the beginning and ending of a connection, as well as sending and processing resets should work as specified.
- Retransmission intervals are increasing exponentially and depend on the round trip time/latency of the path to the remote host.
- TCP options
- Sending mss is taken from the received syn packet and used later. Other received options are ignored. The stack advertises the minimum of the mtu of the according linklayer and the maximum size of the packet buffers as mss/receive buffer.
- integration of other protocols
- Adding other linklayers should be trivial by extending LinkLayer. There is currently only support for one network protocol (ipv4). Transport layer protocols can be added easily by adapting a switch statement in Ip.java. The primary way of extending the stack should be writing application on top of UDP/TCP.
- debugging
- Sending debug output optionally over UDP instead a serial line, which may be handy for boards with only one serial port.
[edit] applications and libraries on top of ejip
Martin has coded a tftp server to share flash contents. He also created a simple http/html server. Both used the pre2008 stack and need little work to be working again.
- tal
- uses the html server(?)
- sms
- for debugging(?)
[edit] NFS
[edit] SMTP
[edit] how to use ejip
Depending on which protocols and interfaces your application wants to use, you need to initialize them. See the programs in the examples dir and the according javadocs on how to do that.
Using UDP or TCP in your application is quite easy. If you want to code a server module you need to implement the Udp-/TcpHandler interface and add it to the handler pool Tcp/Udp.addHandler(port, handler). See the javadocs of TcpHandler and UdpHandler for details.
Client code with UDP is even simpler: fetch a fresh packet from the PacketPool insert your data (e.g. with Packet.setData) and call Udp.send. TCP client applications need to open a connection (Tcp.open) before sending and implement TcpHandler too.
Both, UdpHandler and TcpHandler, need to process data in junks of packets because its convenient for the implementation of the stack. This processing of individual packets is natural for UDP code but unusual for TCP. Therefore a wrapper class (TcpStreamConnection) exists, that is able to circumvent this limitation by using a Packet as scratchpad. Applications using this class can be coded similar to j2se apps using sockets. In difference to j2se sockets, read/write calls in TcpStreamConnection will never block.
[edit] related stuff
how to simulate a slip connection with jopsim and virtual serial ports in windows: SimulatingSlip
