KalvinB - Now why don't YOU jump off a cliff, that would save a lot of people all the trouble...

If asking questions here was a service you you paid for I would understand you beeing upset for replies that answered other things. But now it is free so STFU.

You are not the only person that read the posts and just because you find it useless others don't.



[edited by - cruath on July 17, 2002 10:19:50 AM]

Thanks fingh, gonna be spending a while today googling... Always a pain in the butt when I can''t figure out what terminology I should be looking for.

/empties out the gas can to fuel the fire...

KalvinB - You didn''t tell anyone off. Telling someone off usually requires you having a valid point. You didn''t. So stop. Don''t you understand people aren''t necessarily laughing at the thread anymore, they''re laughing at you directly. Quit while your ahead before you dig yourself a deep deep hole.

fingh, i could not have said it better myself. heh.

being a bit bored, i shall rant now. that gas needs to be put to good use you know, heh.

i think this will become another infamous thread about how the lone poster who solved his own problem had to fight back against those evil oppressors and their damned acts of dissiminating information for the ghastly deed of trying to help right certain misbeliefs that some have.

oh well, sounded better before i typed it.

i can see it now. KalvinB vs Gamedev in a court battle to decide the fate of thread ownership. on CNN there will be a grand coverage on the ramifications and implications this could have. copyright and IP laws changing radically to handle this new style of forum. one in which the the originator of the thread NOT the forum owner/moderators/staff/community claims righst to the contents. heh.

quote:
Apparently the reading comprehension level on these boards is pretty low.

yep KalvinB apparently yours is, thats why explainations came in multiple forms.

though i never felt you told me off. i just felt you enjoyed ignorence, and i wanted to correct that. if i did not succeed at least i helped better explain things for future readers of this thread.

humour and accurate information are a great thing. your "solution" is not complete, and someone who did not know better may copy it and have problems along the way dealing with stuff you are not handling (ie the partial buffer return that occers with recv thus messages that straddle two calls of reciece can happen). heck you even tell us this since you fully acknoledge you are never expierenced partial messages and thus wont bother to handle them till MUCH later (if ever, since you want everything else working first).

a definitive list of resources on TCP/IP for those interested.
http://www.private.org.il/tcpip_rl.html

though i think this sums things up nicly
http://www.erlang.org/ml-archive/erlang-questions/200008/msg00017.html

i removed the email addresses and names, just because i it promotes not using the email in a sapm thingie. you can read the original by visiting the link if yu desire. i did not write the following, its a direct quote from the link sans the names of the innoccent.

the funniest part is that UDP is mentioned, heh. just goes to show that even in a pure TCP discussion UDP can come up for explaination purposes (since many times ppl confuse them a bit in the "packet vs stream" area).

quote:
Subject: Re: Tcp {active, true} problem
Date: Fri, 04 Aug 2000 18:18:31 -0500
cc: erlang-questions@erlang.org
In-reply-to: Message of "Fri, 04 Aug 2000 16:42:03 CDT."


ml> My problem
ml> arises when I send a number of packets quickly( < 500 ms). I
ml> receive them as one large ascii string.

TCP will guarantee that your stream of data will arrive and with the
bytes in the proper order (or let you know something went wrong), but
it doesn't provide any guarantee beyond that. If a TCP stream S is
established between A and B, and A writes 3 chunks of data to S (with
lengths of L1, L2, and L3), you have no guarantee that B, executing
read() or recv() or whatever three times, will read three chunks of
data with respective lengths L1, L2, and L3.(*)

In your greater than 500ms case, you were simply lucky that you got
three reads of the size you were expecting.

If you want that kind of record-boundary-honoring thing, you need to
use UDP. UDP places limits on the maximum datagram size, so that
solution doesn't work in all cases. Your other option is to embed
additional data in the stream itself to tell the receiver where record
boundaries lie.

-Someone

(*) Hm. W. Richard Stevens, _TCP/IP Illustrated, Vol 1_ states this
more clearly? Differently, at least. IMO, every programmer should
have this book on his/her shelf. After reading it all the way
through, of course. :-)

Page 224 says (except for typos):

"A stream of 8-bit bytes is exchanged across the TCP connection
between the two applications. There are no record markers
automatically inserted by TCP. This is what we called a "byte stream
service". If the application on one end writes 10 bytes, followed by
a write of 20 bytes, followed by a write of 50 bytes, the application
at the other end of the connection cannot tell what size the
individual writes were. The other end may read the 80 bytes in four
reads of 20 bytes at a time. One end puts a stream of bytes into TCP
and the same, identical stream of bytes appears at the other end.

"[...] This treatment of the byte stream by TCP is similar to the
treatment of a file by the UNIX operating system. The UNIX kernel
does no interpretation whatsoever of the bytes that an application
reads or writes -- that is up to the application."

aint message archives on the net great? btw, the above quote is for the benefit of those who want to learn and understand TCP and how it works. KalvinB you can ignore it since it merely restates what me, fingh, and others have been trying to explain to you. only this time a quote from a book on TCP is used to explain things. just more ways of explaining it. in fact i think that explaination is damn good, most definatly more clearer and concise then any of mine, heh. i guess thats why i am not an author of a TCP book.

whelp this has been entertaining to say the least. i hope readers of the thread learned a few things.

[edited by - a person on July 18, 2002 2:57:05 AM]