Re: kEADDRINUSEErr and OTConnect() confusion...
Re: kEADDRINUSEErr and OTConnect() confusion...
- Subject: Re: kEADDRINUSEErr and OTConnect() confusion...
- From: Quinn <email@hidden>
- Date: Mon, 10 Nov 2003 15:59:03 +0000
At 14:00 -0800 1/11/03, Alin Pilkington wrote:
1) I don't understand this situation at all since in the OT docs, it
says that if the endpoints are async (and using a notifier to handle
events), the call to OTConnect() should return a KOTNoDataErr and
then upon the T_CONNECT event, the result of the previously issued
OTConnect() can be determined. Why do I get the kEADDRINUSEErr right
away? I don't think it behaved this way on OS 9...
When doing an async operation, you must be prepared to handle the
error coming back immediately or, if the immediate result indicates
that the async operation is proceeding asynchronously, from the
notifier. The implementation is free to choose which errors are
returned via which mechanism on a call-by-call basis.
For example, traditional Mac OS would always return certain errors
(typically parameter errors, like kEBADFErr) immediately, but the
error kEADDRINUSEErr would always come back via the notifier. OTOH,
the Mac OS X OT framework always completes binds immediately (because
the underlying API, BSD sockets, has no asynchronous bind), so now
kEADDRINUSEErr is an immediate error.
2) I'm in need of an education here...which address is it
complaining about as being in use? It can't be the active endpoint
since it is already bound to a port (I used kOTAnyAddress) and got
back no errors in the T_BINDCOMPLETE event. Is it the listener port
on the remote computer that it is complaining about as being in
use?? That is why I tried to increase the qLen of the listener port
thinking that the queue might be full...
The way I read your email, it seems that you're calling OTConnect in
response to a T_BINDCOMPLETE message for the listening endpoint.
That's very unusual. Did I get this right? Who are you trying to
connect to?
Regardless, there are two likely causes of the error.
1. IP_REUSEADDR -- Make sure you set IP_REUSEADDR on your listening
endpoint. See DTS Q&A NW 17 "Unbinding from a TCP Port" for details.
<
http://developer.apple.com/qa/nw/nw17.html>
2. Bind for connect -- When binding the client endpoint (that is, the
one you're going to pass to OTConnect), don't bind it to a specific
address. Rather, use the following code.
err = OTBind(ep, NULL, NULL);
DTS Technote 1145 "Living in a Dynamic TCP/IP Environment" gives the
backstory for this.
<
http://developer.apple.com/technotes/tn/tn1145.html>
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.