[MUD-Dev] Re: datagrams

[Chris Gray]

[Ola Fosheim:]

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

Yes, and the remainder of the packet is discarded, I believe. So, if
your receive buffer isn't as big as the biggest packet you will receive,
then you will lose stuff. Since we were interested in throughput, we
wanted to avoid copying of anything, so we wanted to know the size
of things coming in so we could directly acquire an appropriate buffer.
This becomes more and more important as the communications bandwidth
rises (we first had custom 33 MB/sec interconnect, in the "good old
days"). For UDP, we also had optional run-length compression.

[IP_PMTU_DISCOVER]

I hadn't heard of that stuff. Interesting. It may not have existed when
we initially did our UDP stuff (on SunOS 4.0.3?).

> 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 don't think I follow what you mean here. By default, I believe most
MTU's are something like < 2K. PPP was 1500 bytes. We shipped around
"pages" of 4K - 1 Meg, so we had to fragment them ourselves and reconstruct
them on the receiver.

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

Of course, I wrote it. ;-)

Actually, its sort-of mixed in with multi-protocol stuff that we ended
up doing. Over time we had Fiber Channel, SCI and IBM SP switch stuff.
We chose among them at run-time, so that sorta clouds things up somewhat.

It sounds like it may not be a super good fit with what you need, but
let me know if you want me to persue it further.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



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