Goals?

What do we intend to do?

jet:

Is our intention to create a minimal wordset that provides all the socket behaviors we need?

Do we have the second goal to make it easier to add sockets to Forths which don't have them?

Do we have a third goal?

mlg:

I think, it must answer the following questions:

1. Which set of functions an embedded TCP/IP implementation must provide? (Preferrably, 2 to 6 words.)

2. I want to write an app (embedded/PC-based) that uses TCP/IP. What functions can I use?

3. My platform is ****. Where can I borrow sockets word set code for it?

Please, read KindsOfSocketImplementations.

IMO, the sockets word set must help the programmer who has bare TCP/IP functionality to begin using other people's code.

That is, there must be several levels:

• The hardware control word set (set an Ethernet packet etc.)
• The bare functionality word set, implementor-friendly (send/receive and like that; after implementing these, you may use other people's code of the next category)
• The programmer-friendly word set(s)

jet:

So, 1 & 2 are like a standards problem. Find good names and behaviors.

3 takes code. There are the questions how to use BSD and Windows sockets. Then there's implementing IP in Forth for systems that don't run under BSD-like Unix or Windows. (IP doesn't depend on details of lower levels.) And there's implementing TCP on IP.

Stephen Pelc claims that BSD and Windows C implementations give ugly Forth interfaces. If that work was done independently in Forth it might be cleaner. Would it make sense to do it cleaner or would it be better to emulate one of the others?

Possibly we might create a protocol like TCP on top of IP that was cleaner and simpler, but no one would use it but us.

mlg:

Let me explain what "protocol Y is implemented on top of protocol X" means. It means that in an Y datagram all X headers are present. But it does not mean that SendY calls SendX. Most likely, WriteYHeaders calls WriteXHeaders, if the X headers are enough complex. Always calling SendX from SendY is a nice way to spend real time on something you don't really have to do.

jet:

Yes, or the send routine first writes the Y headers and then the X headers and then calls a layer that accepts the whole message with both headers as its input.

My point is that generic software could be useful even if it is very incomplete. For example systems which accept a low maximum message size can ignore all the datagram fragmentation stuff. To build a webserver you need all of TCP plus a HTTP application. But a small embedded system could benefit from something much more minimal. It might even use some simpler alternative to TCP.