Re: LuaSocket and multiple UDP peers

On Tue, Apr 23, 2013 at 7:53 PM, William Ahern <william@25thandclement.com> wrote:

On Tue, Apr 23, 2013 at 07:23:32PM -0400, Rena wrote:
> If I'm understanding the documentation of recvfrom() correctly, a UDP
> listening socket can receive packets from any peer

Yes, presuming you haven't created an association with connect(2) (in which
case the kernel will filter them), nor bound it to an address which can only
accept packets from a limited set of networks (e.g. 127.0.0.1).

Note that "listening socket" is ambiguous. listen(2) is invalid on UDP
sockets, because they're not connection-oriented, and unlike connect(2)
there's no alternative behavior specified. I assume by "listening" that you
mean simply bound and reading packets.

> and recvfrom() will return the packet plus the address and port it was
> received from. That suggests to me that it's possible to receive a long
> message from peer A, which arrives in two separate packets, and in between
> them arrives a packet from peer B.
>
> I've been writing a socket library myself and want to support the same
> functionality as LuaSocket, in which receive() accepts patterns *l and *a.
> However I'm not sure what to do about this possibility, nor what LuaSocket
> does if you specify *a and receive messages from multiple peers. Does it
> just concat them all together disregarding the source information? Or am I
> misunderstanding how UDP sockets work?

UDP preserves message boundaries, so UDP messages will never be
concatenated. They may be truncated, however--especially if they're very
long*--or lost entirely. Lost** UDP messages are common on high-load
servers--e.g. a DNS server or client sending or receiving many packets per
second.

* They can also be fragmented, but this is transparent to the application.

** Corrupt message are also more common, and on Linux a TOUTTOC bug can be
exposed in poorly written software because select() will poll ready but the
read will fail--Linux doesn't verify the checksum until copying the packet
into userspace. This makes processes hang which assumed it was unnecessary
to mark UDP sockets non-blocking when you didn't want blocking semantics.

Yes, by listening I meant able to receive packets, sorry for the confusion. Am I correct in understanding that a single message sent by a peer will always arrive as a single message at the listening application?

Actually, that still doesn't make it perfectly clear how *a should work with UDP, since the peer itself might split its message into several pieces. It seems like blindly reading until the socket is closed in this situation would be a great way to let other peers interfere with the transmission...

--
Sent from my Game Boy.