quote:

---

Original post by Magmai Kai Holmlor
512 seems a bit small.

---

Thanks for the analysis Magmai, that''s about the most comprehensive breakdown of a UDP packet I''ve seen I keep seeing conflicting information about this topic. I know that UDP packets can be bigger than 512 bytes, but from what I understand anything above that runs the risk of the packet splitting apart on its way to the destination, thus doubling or tripling the chances of packet loss. That''s why I (generally) keep mine below that level (easy to do in all cases, I rarely send huge chunks of data at a time, my average packet size runs more like 100-200 bytes for most things). Is that incorrect?

quote:

---

Original post by kevmo
I found the resource where I got the notion that partial sends could occur: http://www.ecst.csuchico.edu/~beej/guide/net/html/advanced.html#sendall

---

No, but he''s talking about TCP. The method he uses is the correct one for TCP send calls. For UDP, it wouldn''t be right.

quote:

---

Original post by kevmo
Despite the last posters analysis leading to 1400 being a very reasonable number, I would feel a lot better if that were a constant based on getsockopt().

---

The problem is that getsockopt() can only tell you about the local network. Anything beyond that (additional restrictions imposed by routers en route) will not be returned by getsockopt(). If you do want to find out about the maximum packet size at runtime, you''d have to try sending successively bigger/smaller packets and test which one get through without getting fragmented.
The problem with this is that getsockopt

cu,
Prefect

Yes, there are cases where sendto() will NOT send the entire packet you give it. IPv4 only has a payload size range of 16 bits. If you try to send something larger, you will get EMSGSIZE. If you try to send something larger than local MTU, you also get EMSGSIZE. IPv4 only guarantees that data packets of size 548 bytes will traverse all IP networks unfragmented. 1400 is reasonable in most cases, but it is not guaranteed by any specification unless you are restricting multi-play to ethernet. The derivation of 548 can be found various places around the net, it''s not a magic number pulled out of thin air.

The TCP/UDP decision should not be based solely on game genre. I''m working on a RTS-like game that requires UDP. TCP is not sufficient. There really is no reason to mix TCP and UDP during normal gameplay unless you are using 3rd party libraries that require such an implementation. Using both just adds complexity to your design with zero gain.

fingh.