Re: CFSocketIsValid(), select() and blocking
Re: CFSocketIsValid(), select() and blocking
- Subject: Re: CFSocketIsValid(), select() and blocking
- From: Quinn <email@hidden>
- Date: Mon, 13 Oct 2008 09:36:39 +0100
At 2:41 +0800 11/10/08, Liwei wrote:
I'm learning everything as I go along, so sorry for the large amount
of questions!
These basic sockets questions would be answered by any good text book
on sockets. I highly recommend "UNIX Network Programming" (URL
below). It's one of the best programming books I've ever read. Well
worth the investment IMO.
<http://www.unpbook.com/>
First, I would like to be able to tell if a socket (TCP or UDP) is connected.
I know UDP is connectionless, so I'll just need to know if it is
writable now or maybe in the future (i.e. the socket is proper, just
that its currently busy sending/receiving data). For TCP, I need to
know if a client is connected to it, without manually updating flags
when a client connects and disconnects*.
For TCP you can call <x-man-page://2/getpeername>. It will fail with
ENOTCONN if the socket isn't connected.
UDP sockets can be connected, but that doesn't mean what you think it
does. If you want to test whether a UDP socket is writable, you can
use select (with a zero timeout).
Same for CFSocketIsValid(), does it return false when the socket is
valid (?) but currently busy sending/receiving data?
CFSocketIsValid is not really helpful in this context. It validates
the CF state, not the socket state itself.
Second, how do I make sure that only one client can be connected at a
time? Do I just disable the kCFSocketAcceptCallBack after the first
client connects?
It depends on the behaviour you want on the wire:
o If you want connections to be queued indefinitely, just accept the
connection but don't process it until you've done with the previous
connection.
o If you want connections to be queued up to a small limit, disable
the accept callback. The connections will back up in the kernel up
to some pre-set limit (in theory this is the value you pass to
<x-man-page://2/listen>).
o If you want connections to fail, shut down the listening socket.
Third, is it safe to not close sockets before I terminate the application?
Define "safe" (-: It is safe as far on the local kernel is
concerned. It's also safe in terms of the TCP protocol on the wire.
It may not be safe for whatever protocol you've defined on top of
TCP, but that's your problem.
Fourth, how does SO_REUSEPORT affect my sockets?
The exact behaviour of SO_REUSEADDR / SO_REUSEPORT is quite complex.
I don't fully understand all of the nuances myself, certainly not
enough to offer up a full description here. Do you have a specific
question?
* Fifth, how am I notified of a client disconnecting?
For TCP, the socket will become readable and a read will return 0 bytes.
For UDP, this question makes no sense.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden