|
On Tue, Apr 23, 2013 at 07:23:32PM -0400, Rena wrote:Yes, presuming you haven't created an association with connect(2) (in which
> If I'm understanding the documentation of recvfrom() correctly, a UDP
> listening socket can receive packets from any peer
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.
UDP preserves message boundaries, so UDP messages will never be
> 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?
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.