[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaSocket and multiple UDP peers
- From: William Ahern <william@...>
- Date: Tue, 23 Apr 2013 16:53:01 -0700
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.