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

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

AP:

"Please stop treating gamedev as your personal resource"

I''m treating this thread like my personal resource because it is.

If you don''t like it, start a new thread.

Ben




IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

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.

Apparently threads labeled "UDP vs TCP" and "Network Programming with UDP examples" weren't a big enough clue that in those thread people are discussing what you're looking for so there's no need to start a new one.

I'm sure you're just trying to make some sort of point but when there are currently 2 or 3 threads dedicated to UDP you look pretty stupid asking about it in here. You're also pretty arrogent demanding people repeat themselves just because you want to "prove" something.

Let me help you out

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]


[edited by - KalvinB on July 16, 2002 4:11:21 PM]

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

/stop flame war

Well, I see that the topic has taken a turn for the worse, but I''ll take a shot at a question anyway.

Isn''t there a way to flush the TCP/IP stream manually? I know there isn''t going to be any way for the program to know if data is going to be split up by the routers between the server and the client, but it could do a bit of guesswork to find out. I think flushing the stream every time might be a bit too much overhead (correct me if I''m wrong there).

What you could do is measure the packet size. If it''s under 128 bytes, you''re generally safe to just send it without it being split up, even over a modem. Beyond that, you won''t really be able to tell. Also, measuring the time between one transmission and the next might be possible. If it''s less than 50ms, then flush the stream and transmit the next ''packet''. You would have to do a lot of experimentation to find the exact tolerances of the routers, but I''m sure you could do it.

Again, I''m kinda doing some guesswork here. I haven''t worked with TCP in a while (6 months or so) and my brain is full.

/resume flame war

---

Looking for an honest video game publisher? Visit www.gamethoughts.com

"Ah... so you would suggest I search through other threads, where people have gone beyond answering the original poster''s question, for information?"

You''re kind of dense aren''t you? If you posted your UDP questions to a UDP thread it''s what we call staying "on-topic." Talking about UDP in a TCP thread is what we call going "off topic." And it''s never appreciated. Read Slashdot once and see how well moderated off topic posts are.

"If so, then how can you truely discuss TCP without implicitly discussing UDP."

That almost sounded intelligent. See, since my original post dealt strickly with a TCP issue, UDP has zero relavence since nothing UDP related would solve my problem as indicated by the solution I gave both in the original post and the post with the solution in code. I realize this is a very difficult concept for you people.

I never realized how difficult it is for people to stay on topic or start a new thread.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

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