quote:Original post by KalvinB
Get off you''re little horse and sit down. Apparently you''re having a tough time accepting that your advice isn''t needed AT THIS TIME as I''ve said a number of times. If I had a question about partial packets I''d ask.

As has been stated before, this thread is not for your sole benefit. Please stop treating gamedev as your personal resource. You don''t pay to have your questions answered here.

So um, anyone want to talk about UDP?

mwahaha

Nope, don''t believe I will, although perhaps the AP will. So, would anyone like to discuss UDP and particulars of why it''d be more appropriate in this situation? Preferably dumb it down a little, if possible maybe just highlight a few terms that I should google for.

Ah... so you would suggest I search through other threads, where people have gone beyond answering the original poster''s question, for information? Usually I would, except you seem to be telling people they shouldn''t be adding extra information to any threads that don''t require the information to answer any questions posed. Such as this thread, where you''ve told people to leave ''your'' thread if they''re going to talk about anything except what you specifically dictate they may. Perhaps you''d like to simply choose one of these options: People may voluntarily post extra information to threads where it may be pertinent to people browsing in the future and make it more useful; or have everyone post new threads asking for only the information that exactly answers their current question (what you''ve done so far).

Isn''t TCP built on top of UDP? If so, then how can you truely discuss TCP without implicitly discussing UDP.

As a result, the whole VB in a C++ thread thing doesn''t apply. It''s more like Assembly in a C++ thread. VB in a C++ thread would be a better metaphor for someone suggesting you use IPX when you are asking about TCP/IP.



--TheMuuj

Muuj: Actually, TCP is built on top of IP, so is UDP. I wouldn''t say TCP is built on top of UDP, because that is an implementation-specific detail that you probably don''t know, and shouldn''t care about. (not you specifically, "you" as in the application programmer)

mtaber: How would you manually flush the stream? I don''t personally know of any way to do it. TCP imposes a delay for nagling, and another delay for acknowledgements. Combined, those delays can easily be as high as 250 ms in some implementations. Note, however, that nagling can be turned off (but not delayed acks). Making sure you have MTU-sized messages when you call each send() is also a helpful way to get your data through the buffers, although it still doesn''t mean it will be intact for a single receive.

quote:
"People don''t want to admit they don''t know how to do something, so they promote the easiest way around it."

No, people don''t like when other people just assume they don''t know how to do something and then go on and on about it.

KalvinB, please stop. I dedicated 17 words to UDP in my original post, you are the only one going on and on about it.

Melraiden:
UDP wouldn''t necessarily be more appropriate here, but it more closely resembles what it seems the original poster was expecting (receiving message boundaries in tact). If you want to know more, search google for: nagle, delayed ack, congestion avoidance and inherent latency. You should find a couple weeks worth of reading...