Embedded Internet

James Cameron says:

TCP flow control can be just ignored. Packets get repeated. Not nice, but it is better than not communicating. I think the RFC allows for this for embedded devices.

William Chops Westfield says:

The inet host can fragment a large IP *packet* into smaller fragments, but it can't fragment a TCP *segment*. If there was a single large TCP segment fragmented into tiny IP packets, it would get reassembled on the destination host BEFORE TCP got to look at it, and then TCP would claim that it's too big.

Whats the size limit on SLIP? Originally, 1006. Practically, 1500 or so (ie same size as an ethernet packet.) Fundamentally, 64k...

I would expect that there's quite a lot one could do within the confines of 536 bytes of payload. In the absense of huge graphics and fancy HTML, that's quite a bit of data for a small microcontroller to have to send in the first place, right? I think some sort of "eternal filesystem" to hold the "pure data" part of the conversation is fundamental to TCP on very small microcontrollers. A serial eeprom/flash device would work fine.

...also see: NCSA telnet, an "open source" (but predating that term) application/OS/Internet stack that runs on DOS. a 1990 ("pre-bloat but post-64k-frugal") implementation has a "minitel.exe" program without too much extra stuff (like tektronix terminal emulators) and is about 93kbytes (for the exe file.) Other possibilities include "ka9q" - a similar project targetted (restricted?) to ham radio applications.

PIC specific Internet

SX specific Internet

Denis Petrov's PIC 16F84 implimentation of TCP/IP, HTTP, CGI (?) with source! Mirrored from his hompage at: http://www.chat.ru/~zhengxi/wwwpic/source.htm

Methods@ TCP/IP, Internet of Things

See also:

Questions: