Re: [colorforth] TCP State Engine

[Jonah Thomas <j2thomas@xxxxxxxxxx>]

John Drake wrote:
> Mark Slicker <maslicke@xxxxxxxxxxx> wrote:
>> John Drake wrote:

> For clarity I'll repost that part of the
> conversation:

> =====================================================
> The point is, if you want a web browser you have
> to be compatible with as much of the existing
> complexity as you want to browse.  That isn't
> going to be any 3-block solution.  You might
> get TCP in 3 blocks, maybe, but you aren't going
> to get much of a web browser that way.

That was my claim.  I can believe a 3 block TCP, I have trouble
believing a full-feature 3-block graphical web-browser.

> If the messages you want to send and receive
> over TCP are your own kind, then you can do
> it the way you want.  It won't compete with web
> browsers but it might be perfect for
> refrigerators and stoves and such
> to communicate over the net.  You might find
> a better way for a bunch of Motes to communicate than
> what they have already.  There are lots
> of potential applications besides web browsers.

TCP has many uses beyond web browsers to put pretty pictures on
screens.  Find a new one and you can set the standard, and make it
as simple as it should be.  A standards committee may come along
later and complicate it, but maybe they'll add mostly *optional*
complications.

> And there's the question whether you need more than one
> UDP packet at a time.  If you can put everything into
> one UDP packet then you don't need to implement all of
> TCP.  You still want to confirm that packets get
> through, but you don't need much packet reordering
> etc.  So implementing just the part of TCP that you
> need first might split the problem into easy pieces.

If it's your application, say something in process control, and you
can keep it simple, maybe you won't need all of TCP.  All that short
messages need from TCP is to find out about dropped messages.  You
won't have to split messages and re-order packets etc.  So
implementing just that part is enough for that application.  Or maybe
implement over UDP, whatever works.

I looked at uip.0.9.tar, a TCP/IP in C whose authors consider minimal.

--------
"Traditional TCP/IP implementations have required far too much
resources both in terms of code size and memory usage to be useful in
small 8 or 16-bit systems.

"The uIP implementation is designed to have only the absolute minimal
set of features needed for a full TCP/IP stack. It can only handle a
single network interface and contains only a rudimentary UDP
implementation, but focuses on the IP, ICMP and TCP protocols.

"Many other TCP/IP implementations for small systems assume that the
embedded device always will communicate with a full-scale TCP/IP
implementation running on a workstation-class machine. Under this
assumption, it is possible to remove certain TCP/IP mechanisms that
are very rarely used in such situations. Many of those mechanisms are
essential, however, if the embedded device is to communicate with
another equally limited device, e.g., when running distributed
peer-to-peer services and protocols. uIP is designed to be RFC
compliant in order to let the embedded devices to act as first-class
network citizens.

...

"The RFC1122 requirements can be divided into two categories; those
that deal with the host to host communication and those that deal with
communication between the application and the networking stack. An
example of the first kind is "A TCP MUST be able to receive a TCP
option in any segment" and an example of the second kind is "There
MUST be a mechanism for reporting soft TCP error conditions to the
application." A TCP/IP implementation that violates requirements of
the first kind may not be able to communicate with other TCP/IP
implementations and may even lead to network failures. Violation of
the second kind of requirements will only affect the communication
within the system and will not affect host-to-host communication.

"In uIP, all RFC requirements that affect host-to-host communication
are implemented. However, in order to reduce code size, we have
removed certain mechanisms in the interface between the application
and the stack, such as the soft error reporting mechanism and
dynamically configurable type-of-service bits for TCP connections.
-------

If the C guys can do it in 4K of code (plus a few hundred bytes RAM
for one buffer, when you get a packet out of order you discard it and
ask them to resend it later) then likely you could do it in ColorForth
in 3 screens.  But the specs are tremendously complicated, and then
you also have to follow common practice.  If common practice doesn't
follow the specs you lose by following them.  And these guys say the
specs for communicating with other TCP/IP nodes are complicated, at
least for error conditions.  This particular implementation has more
than 300K of documentation and a significant fraction of it is
describing the complicated problem they're trying to solve.


So again, to use TCP to communicate between two Forth systems, all you
need is to correctly do the part that intermediate nodes need, plus
what your application needs itself.  If you want to communicate with
other people you must follow their standards which are unnecessarily
complicated.

> =====================================================

> Now reading this I get the impression that Jonah
> is saying that in order to support a full web
> browser you would need to implement more then the
> "part of TCP" that could be done in three blocks.
> I feel that TCP is TCP.

No, I say that if you *don't* need to support a full web browser you
can get by with just the part of TCP that you do need.  Maybe some
sort of UDP+.  If you *do* want a full web browser then you must
handle all the web pages that were designed for IE4.  That might be
real complicated, but doable.  It takes the full TCP which probably
isn't so bad, but the web browser is even worse about complicated
standards and common practice that doesn't match the standards.

> Right.  You and Sam are in AGREEMENT so I don't
> see your point of making an issue here.

Yes, I don't see why venom poured from more than one of us.

>>>===========================================

>>No one has talked about "refrigerator browsers".

> Jonah did.  See above.

Yes.  If you can make inexpensive Forth processors that connect to the
net, why not put one in a refrigerator?  The first model tells you
when it needs a service check and warn you when it notices something
going wrong.  A later model might have a scanner, it calls your
grocery store to find out what the bar codes mean and you can call in
and find out what's in the fridge from your cellphone etc.  Later
still you might tell it to move things from freezer to cooler to let
them thaw, or even put things into the microwave or oven while you're
on the way home.  This may be mundane but it's one small application
that could generate a few hundred thousand sales and several small
programming projects over the years.

And does your refrigerator have to say how to format a webpage? It
could give you the data and let you decide how you want it formatted.
Or dump it to a database.  If it's your application you don't have to
meet web-browser standards.

> Right.  But Sam wasn't embracing that idea.  Once
> more read who mentioned "refrigerator browsers".
> And to be fair to Jonah he didn't say that Forth
> is only appropriate for "embedded systems" but he
> seemed to imply that a TCP block that consisted of
> only 3 screens would only be good for refrigerators,
> stoves, motes i.e. embedded systems.

I think 3 screens might be *all you need* for TCP *plus* application
layer for some of those.  Like, the most vital thing a stove can tell
you is whether you turned it off when you went on vacation, and the
most vital thing you can tell it is to turn itself off.  You could
probably do that in the space left over on your UDP screen.  Tell it
to turn off.  If it doesn't answer, tell it again at 5 second 
intervals until it says it did it or you give up.  No need for TCP.
It could sell a few hundred thousand chips and one tiny software
project.

> Second this is appropriate to the discussion
> since Jonah said:
> =============================================
> You might get TCP in 3 blocks, maybe, but you
> aren't going to get much of a web browser
> that way.
> =============================================

> So some people might be interested in what
> does/does not define "much of a web browser".
> If you don't want to hear this part of the
> discussion then tune it out, because frankly
> all you are adding is noise at this point.

I figure web browsers have become kind of like commodities now, if it
doesn't do the standard things then people will only use it for things
commodity browsers don't do.  I think most users won't use a browser
for more than a few days unless it gives them a decent graphical view
of most of the web pages that were designed for IE4, with javascript,
java, flash, and various plugins like .wmv and .avi and .mpeg .  And
free.  Maybe the people who don't want that kind of browser are an
elite, but they look to me like a small elite.  On the other hand, web
servers look like they could be pretty easy unless your site gets
popular enough to get a lot of traffic.  So again, it makes sense to
me to first go after other applications than a full-service web
browser, and it might make sense to start with applications that don't
demand all the capabilities that TCP provides.



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com