[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: luasocket invalidates its internal state by closing the socket when setsockname() fails
- From: Ted Unangst <ted.unangst@...>
- Date: Sat, 20 Mar 2010 12:09:35 -0400
On Fri, Mar 19, 2010 at 8:41 PM, Sam Roberts <firstname.lastname@example.org> wrote:
> On Fri, Mar 19, 2010 at 4:22 PM, Ted Unangst <email@example.com> wrote:
>> On Wed, Feb 24, 2010 at 6:34 PM, Sam Roberts <firstname.lastname@example.org> wrote:
>>> This is purely a luasocket behaviour. The system calls allow bind() to
>>> fail, leaving the socket valid.
>> Only on some systems.
> a) If such a system exists, wouldn't this be considered an unfortunate
> bug in that system?
Well, it's been like that for 20 years... But I may be mistaken, I
was thinking of connect, not bind. It's been a few years since I
actually had this problem.
>>> This behaviour of luasocket is particularly anti-social when
>>> attempting to repeatedly bind to local ports, to search for one that
>>> is free.
>> You're supposed to create a new socket after a failed bind. Read your
>> Stevens. :)
> b) Do you have a page or section reference?
> I find no mention of this in "Unix Network Progamming - Networking
> APIs: Sockets and XTI", 2ed, under the bind or udp docs, but its a big
> book. I have copies of TCP/IP illustrated, too, if you find this claim
> in them.
> Also, those books are old. In none of these do I see a claim that
> returning an error invalidates the descriptor:
> I do see "A process with a connnected UDP socket can call connect
> again for that socket." (p.226, also the freebsd man pages). This
> isn't supported by luasocket, either, connected sockets can only be
Ah, sorry, no reference, other than the man pages (for connect, not bind, oops).
For UDP, you're certainly right. I was thinking of the stream behavior.
"Generally, stream sockets may successfully connect() only once;" I
think this is often interpreted to mean "one successful connect" but
the implementation is actually "only call connect() once,
The problem exists in OpenBSD and FreeBSD. Possibly Mac, I didn't
test at the time. Sorry for the hazy memory.