Re: Unbinding an endpoint in OT when running in Classic.
Re: Unbinding an endpoint in OT when running in Classic.
- Subject: Re: Unbinding an endpoint in OT when running in Classic.
- From: Justin Walker <email@hidden>
- Date: Wed, 14 Apr 2004 23:02:40 -0700
On Apr 14, 2004, at 22:23, Graham Parkinson-Morgan wrote:
Sorry to have to come back to this again, but after further analysis,
I'm afraid that my problem with OT in Classic hanging onto a port for
grim death did not go away.
To recap: I have a test app that is compiled in three separate
configurations:
A: for PPC, using OT.
B: for Carbon using OT.
C: for Mach using Unix and CFSockets.
All three apps are fired up at separate times during testing on OSX
10.3.
The endpoints/sockets are all set up with for UDP protocol with
options to IP_REUSEADDR, IP_REUSEPORT, and IP_BROADCAST. Thanks to
Justin for indirectly pointing out that I had forgotten the
IP_REUSEPORT option for the OpenTransport configurations.
I find that configuration B(Carbon using OT) can be fired up, run, and
shutdown as many times as I like and the test port (port 7000) is
bound and released happily every time.
The same story for configuration C (Mach), both before and after
running configuration B (Carbon using OT).
However, the fly in the ointment is A(PPC, using OT). When I fire this
for the first time, Classic launches, port 7000 is bound to the
endpoint, the app is run, data is received on that port, the endpoint
is unbound, exactly as for configuration B, and I quit the test app. I
find that I can relaunch the application and the port, according to
Classic, is available: it can be bound, is bound, will receive data,
gets unbound, I can quit the app; and this cycle can be repeated for
as long as it takes for all to be satisfied that the mechanism works
in Classic. All is well until I go back to configuration B or C (at
this time, I have quit A). Now, in B, a call to OTBind for port 7000
will return kEADDRINUSEErr: in C(CFSockets & Unix), a call to bind
will return -1 with errno = EFAULT.
EFAULT would (to me) indicate another problem. I believe that this can
only occur if there is a problem with your use of the system calls.
AFAIK, there is no way for bind() to return EFAULT, unless one of your
arguments (a pointer into your address space) is bad.
Shutting down Classic will not help: the port is stubbornly
unavailable: and remains so for as long as I care to test it ( had
supper, came back, checked if anything had timed out, etc). Rebooting
OSX, in my complete ignorance, is the only way I have found to restore
the beloved port 7000 to its former glory.
There could well be a bug in the interaction between Classic and the
Mac OS X IP stack. The former is supposed to allocate ports via calls
to the latter, and release them. It may be that this isn't being done
reliably. If this is the case, you should see the socket allocated
when you use "netstat -ta", and the socket state should be "11" instead
of one of the typical terms (like ESTABLISHED). The kEADDRINUSEErr is
telling; I think the EFAULT from case C is just obscuring things.
Depending on which way you're headed, traversing the learning curve can
be like sliding down a razor blade :=}.
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | It's not whether you win or
lose...
| It's whether *I* win or lose.
*--------------------------------------*-------------------------------*
_______________________________________________
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.