Re: [colorforth] TCP State Engine

[John Drake <jmdrake_98@xxxxxxxxx>]

--- Jonah Thomas <j2thomas@xxxxxxxxxx> wrote:
> 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.

But I don't know of anyone who has claimed that a
full featured graphical web-browser can be written
in 3 blocks, so I'm not sure I follow your point.

>  > 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.

The last sentence is the only one that I can follow.
If your message fits in one UDP packet then just
use UDP.  I don't see the point of stripping down
TCP to UDP.

>
=====================================================
> 
>  > 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.

Ok.  It looks like you just said what you say you
didn't say.  Two points and I'll let it go.

1) Much of the complexity of IE4 has nothing to
do with TCP so it's a bad example to use.

2) You're saying "it takes the full TCP".  So, to
me, that's saying that you believe the TCP required
to handle a full web browser will take more then
3 blocks.  Is that what you're saying or not?

Regards,

John M. Drake


	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

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