[MUD-Dev] Re: datagrams

[Ola Fosheim Grøstad <o.f.grostad@notam.uio]

Chris Gray wrote:
> If you change your basic datagram size, how do you co-ordinate that size
> change between sender and receiver? The receiver has a 'recv' call
> outstanding - if that doesn't match the size that the sender sends,
> can you recover?

Hmm.. Well, I have only run some simple UDP tests, but

lunix> man udp

       All receive operations only return one  packet.  When  the
       packet  is  smaller  than the passed buffer only that much
       data is returned, when it is bigger the  packet  is  trun-
       cated and the MSG_TRUNC flag is set.

It also says:

       UDP  fragments  a packet when its total length exceeds the
       interface mtu.  A better more polite alternative is to use
       path  MTU discovery and send data in right sized chunks so
       that no fragmentation  occurs.   Linux  2.2  automatically
       keeps  track  off  the  path MTU of a specific destination
       when  the  IP_PMTU_DISCOVER  socket  option  is   set   to
       IP_PMTUDISC_DO.   UDP  will  return an EMSGSIZE error then
       when the datagram length exceeds the path MTU and save the
       new pmtu in the error queue if enabled (this is a path mtu
       recovery event).   To  bootstrap  the  pmtu  discovery  on
       unconnected  sockets  it  is  possible to start with a big
       datagram size of 65536 and let it shrink by pmtu discovery
       events.   When  the socket is connected to a specific peer
       with connect(2) the path mtu can be retrieved conveniently
       using  the IP_MTU socket option.t For connectionless sock-
       ets with many destinations the discovered MTU per destina-
       tion  can be accessed using the error queue after a pmtud-
       isc recovery event occurred (see ip(4) for an  description
       of  the  error  queue).  The  application  shall lower its
       packet sizes then to the new path MTU. To get  an  initial
       estimate  of  the PMTU it is possible to connect an tempo-
       rary socket to the destination address  and  retrieve  the
       MTU using the IP_MTU getsockopt.

Although this makes sense on a local network, does it make sense for
packets that is relayed through 7-12 node with possibly different MTUs
(maximum transfer unit)?

> of our messages were header-only. On Windows NT, the exact same code
> ran abysmally, and we never were able to get decent performance. We
> also tried using WIN32 named pipes, and they were better, but still
> abysmal. Shrug!

I don't plan on writing server side stuff for WIN32 ever! :)   I'm
trying to figure out how to avoid learning MS stuff for the client side
as well.. (OpenGL + Qt + CommonC++ ?)

> want to ACK arrived. Putting 3 or 4 acks/naks in the fixed header of
> each message works pretty good. I believe TCP does something like that.

Ah yes, I will send many messages in a single datagram.  I plan on using
serial numbers on messages rather than datagrams, to make resizing
easier.

> I use TCP for my binary protocol. UDP is a pain, and perhaps hard to get
> going well on non-UNIX systems. We had to use UDP at work, but so far,
> TCP has worked fine for my MUD client.

Really? Well, I plan on using a toolkit for clients if possible. Maybe
CommonC++ (formerly known as APE, you can find it on sourceforge) or Qt
(troll.no) if they support UDP...

> Hmm. I'd have to steal it from work, if you want the UDP stuff. It's
> *possible* that it would be OK for me to send you the whole sources,
> but I wouldn't bet on it! :-)

Ah.. Nice offer... But is it comprehensible? :)

--
Ola




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev