Re: Unbinding an endpoint in OT when running in Classic -- solved.
Re: Unbinding an endpoint in OT when running in Classic -- solved.
- Subject: Re: Unbinding an endpoint in OT when running in Classic -- solved.
- From: Justin Walker <email@hidden>
- Date: Thu, 15 Apr 2004 15:13:40 -0700
On Apr 15, 2004, at 14:16, Graham Parkinson-Morgan wrote:
I would not have expected to be penalised for calling OTUnbind before
destroying the endpoint, and indeed, leaving out this call made no
difference.
Who knows what evil lurks under the surface of an API? :-}
I created a console app, and gradually added in our cross-platform
socket stuff almost line by line until Classic grabbed the port.
I now see what is happening, and have (provisionally, at least) cured
the problem.
The code is set up to have a udpbroadcaster class and a udplistener
class. Each has its own socket/endpoint.
For the broadcaster instance, from what I can gather, even though it
is not 'listening' to a port, it still has to be bound to an address
and port number: the port number defaulted to 0. So OTBind was called
with an address of kOTAnyInetAddress and a port of 0, returning noErr.
Changing the code so that broadcaster objects each got a fresh port
outside the range of privileged ports restored sanity, so now
Classic's port grip of death appears to have vanished.
I'm not clear on what you mean. Are you requesting a specific
(non-zero) port for each active (non-listening) endpoint?
Thanks for all your input.
Of course my question is, why does OTBind allow binding to port zero,
and, as it turns out, why does it appear to allow binding to port zero
more than once (there can be several 'default' broadcasters). Is there
something magical about port zero, as there is for the address
kOTAnyInetAddress/INADDR_ANY?
Port 0 is 'magical' in that it is not a valid port number (it is
reserved by IANA).
Typically, and I believe OT uses this convention, a bind() with a zero
port tells the kernel (or the port-assigner) that it should allocate an
unused port in what's called the "ephemeral range" (the high end of the
port number space). That way, your app will not have to scan for an
unused port.
You should be able to verify this behavior using the moral equivalent
of the BSD call getsockname().
I have no clues to spare on this one. Perhaps Quinn can get his
flashlight out, and shine some light into the dark corners of the OT
support on Mac OS X.
FWIW, if you are going to spend a lot more time in this endeavor, it
might be worth your while to invest in Stevens's "Unix Network
Programming, v1, 2nd ed.". It goes into grand detail about programming
in BSD/Sockets and XTI APIs, and discusses a lot about the BSD-style
stack implementation, and how to get the most out of it.
Regards,
Justin
--
/~\ The ASCII Justin C. Walker, Curmudgeon-at-Large
\ / Ribbon Campaign
X Help cure HTML Email
/ \
_______________________________________________
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.