[MUD-Dev] Re: datagrams

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

Chris Gray wrote:
> 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.

Yeah, and then you can resize your buffer and don't send "acknowledge".
But I will always use an upper limit. I don't mind the copying as I
would like to process and discard as soon as possible.

> [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?).

There seems to be new options coming along all the time. Rather
confusing for a person like me that is not really interested in the
network itself. I don't find anything on PMTU on the SunOS IP/UDP man
pages I've got. *comfort* *grin*

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

Well. I stuff many messages in the same packet, as a message can be only
a few bytes long and I want to avoid the header overhead. But if I don't
get acknowledge then some messages may be outdated already and there
would be no point in sending them again, or maybe I have to reduce
packet size to avoid fragmentation and thus get them through in heavy
weather. That would create trouble for a packet oriented sequence
numbering. Not sure if it is worth the trouble to complicate things like
this, but I certainly want to be able to optimize later on if necessary.

[Chris' protocol]
> 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.

I don't think it is a super good fit either, as I am more concerned
about responsiveness than throughput of files.

--
Ola  -  http://www.notam.uio.no/~olagr/





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