Confused about Ethernet-Internet-TCP-UDP-HTTP-Network

Heavy discussions are going on about "Embedded Ethernet". And then immediately the term "TCP/IP" is brought into the discussion. Many people equal all terms so it seems all is the same, or TCP/IP is Ethernet and also Internet.
Only one is absolutely true: Embedded Ethernet has a big future. But there is many fog around. But remember most terms rely on "Embedded Ethernet" and not on "Embedded TCP/IP". Any implementation of an Ethernet driver is called a Network Stack or "NetStack". This for clarification of used terms.

Our target was also to implement the complete TCP/IP with all layers. But when we studied present implementions we saw that one part of them was Mickey Mouse and the other part was extreme huge (>30k).

We tested a very well designed system called "L..." (mega103) found in the WEB. But a short bombard with packets let the system crash. Disappointed. Others seemed to be quick and dirty. A PIC with a complete TCP/IP HTTP stack in 4kBytes of ROM?? Can befound.

So we sat down and said: back to the roots. What will we do with an AVR and Ethernet? Building a WEB browser? Building a WEB server? Sending e-mails? Receiving e-mails? Building a FTP server or client? Not at all. Think of a network connection is similar to a RS232 serial connection. The Ethernet is "only" an additional way to communicate with others, not more and not less. If one want's to build a WEB server, use a PC104 with a Linux. That's cheap, fast and small.

Sending messages and receiving control packets in an extremely short time with a short response on a secure way. That's the goal!

The result was: we need a high speed packet transfer from board to board. From PC to board and vice versa.
This transfer must be very secure. Packet losts are not acceptable. We need very high speed, the packet time must be below 10msec in order to resolve realtime jobs.

Any TCP protocol doesn't fit to these requirements. The only possible solution is UDP/IP. A WEB investigation showed that all industrial Ethernet implementation (Motorola, Siemens, ProfiBUS etc) use the UDP for realtime jobs.

But there is a heavy drawback with UDP/IP. UDP is a very unsecure protocol. This means the sender doesn't know whether it's packet has been received by the receiver. If a packet gets lost both parts can't know it. Further, if the packet has been received the receiver can't see whether the data part of the packet is valid or not. Wrong or missing data can't be determined. Two big problems which makes standard UDP unusable for control applications.

Analyzing the industrial (control) UDP implementations showed that they all use an additional handshake and checksums. This is the solution. Extrem high speed UDP/IP with additional handshake and data checksums. Sure, this slows down the data transfer rates somewhat. Nevertheless this scheme is very much faster than the pure TCP/IP protocol and it is secure!!

After these research results we decided to implement an extended UDP/IP called xUDP. It's absolutely secure and very fast. Board to board connections are very simple. PC to board connections can be established with the E-LAB xUDP Mapper program.

E-LAB xUDP Mapper
What is a Mapper??
Because our intention was to implement a secure and high speed Ethernet protocol, there is no direct TCP/IP (FTP, HTTP, TFTP, TelNet, e-mail etc) support in our NetStack. But that's normally no problem. High speed transfers can be done always with xUDP. If for example a FTP communication is necessary, a "GateWay" must be used. Our PC-based xUDP Mapper is such a tool. It is always active on any PC in the LAN, running invisible in the background. If any xUDP stack in this LAN requests a FTP transfer the xUDP Mapper becomes active and maps the xUDP packets into FTP packets and vice versa. These packets now are redirected to or from the corresponding FTP server. This is always transparent for all participiants. Future releases will also support other protocol types including e-mails.

The PC program xUDP Mapper serves 4 jobs.

1. Configuration of any board with the xUDP kernel. IP-address, MAC-address, Boardname etc.
   This must be done with the serial Interface RS232 between PC and board.
2. Testing boards with a board scanner and a pinger.
3. Translating the xUDP protocol to any other protocol. So the board can be contacted via FTP and the board
   can be upload data to any FTP server in the local net and/or worldwide net.

Corresponding in semi realtime with each other PC etc. worldwide via a chat like mode.

Similar tools and programs can be found in the Internet for several $1000 :-)

So with the help of any PC in the local network the xUDP stack can also do most of the common TCP/IP protocols
without exploding the FLASH or RAM or burden the AVR with such difficult protocol handlings.

With an existing 6.4MHZ AVR mega system the ping time for 65 bytes is 3msec, a standard ping lasts 4msec and a 1.5kByte ping lasts 10msec. New upcoming AVRs will nearly double the speed

The xUDP packet time is always below 10msec if the packet size is in range of a few hundred bytes. This can be called "realtime".

The kernel size is about 6kByte, RAM useage is about 400bytes plus two buffers (Rx/Tx). So our system can be easily
implemented into a mega161, mega163, mega32 etc.

The xUDP driver is a part of the AVRco Pascal Profi Version. At this time only the RTL8019 Ethernet chip is supported. A later version supports a generic driver where the programmer can implement his own network driver/chip.