Re: Open Transport -3168 more info
Re: Open Transport -3168 more info
- Subject: Re: Open Transport -3168 more info
- From: Andrew Bush <email@hidden>
- Date: Fri, 22 Nov 2002 19:26:29 +1300
Hi all,
OK, a little more info, it seems that there was a bug in my error checking
code (god help me)
What was happening is that some sockets were returning *6* as their
endpoint state, T_OUTREL, with an OTLook value of 4, I was then calling
.SndDisconnect on them, and the endpoint was moving from there into T_IDLE,
and from there calling OTBind would consistently return kOTStateChangeErr.
Doing as was suggested and calling OTCLoseProvider (following a IOCTl
flush call) appears from early tests to be working nicely.
So I think that puts me firmly into Bob Cooks problem :) is this an OT
bug or something we are likely doing wrong?
Thanks for your help.
Yours cheerfully,
Andrew Bush
On Friday, November 22, 2002, at 06:06 PM, Bob Cook wrote:
Hi,
I recently ran into a similar problem when I tried to cancel outstanding
asynchronous ::OTConnect() function calls on Mac OS X.
My code creates endpoints in sync mode, then switch to use asynchronous
blocking plus a notifier, followed by a call to ::OTConnect(). After some
period of time, I attempt to cancel the pending connection with
::OTSndDisconnect(). This works exactly as expected on OS 9.
Unfortunately under OS X I find the endpoint goes from T_OUTCON into
T_IDLE, but calling ::OTUnbind() consistently returns kOTStateChangeErr.
It never recovers into T_UNBND. In my case ::OTLook() always returns 0.
This behavior was 100% consistent.
My solution is to call ::OTCloseProvider() instead of ::OTUnbind() on Mac
OS X. Under OS 9 I continue to use ::OTUnbind() followed by
::OTCloseProvider() since it seems to work reliably.
Two questions:
(1) Is this strategy going to cause me problems in other places? How
sensitive is the OT shim on OS X to these sorts of behaviors? My past
experience with OT has been that its best to "follow the rules" but that
seems unlikely to be possible in this case. Am I doomed? Or will it all
work out ok?
(2) Am I the only one seeing this behavior? I guess its worth asking
since my perusal of the archives only discusses canceling synchronous
calls to ::OTConnect() [where my experience is with async mode]. I was
able to reproduce this on 10.1.5, 10.2, and 10.2.2. I don't have other
versions readily available to test with, but my feeling is that this is
not new.
Thanks,
Bob Cook
On Thursday, November 21, 2002, at 12:21 PM, Rich Kubota wrote:
An OTLook result of 4 is a T_DATA event has occurred on the endpoint.
OTLook returns event codes, in contrast to error codes. Normally it
returns T_DISCONNECT, etc.
The result of 4 doesn't make sense since you have reported the state to
be T_IDLE. In a previous response on a question regarding
OTGetProtAddress returning the kOTStateChangeErr, Quinn indicated that
the possibility of a bug in the OT Framework - where possibly and
endpoint lock was left set.
Since the endpoint is not in use, how about calling OTCloseProvider on
the endpoint and reopening the endpoint during task level time.
_______________________________________________
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.
The word for a society where everyone is pulling together is 'Tyranny', in
a free country everyone tends to pull in different directions.
_______________________________________________
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.