Yeah, yeah, I know - it's ancient history, etc. etc. etc. Can we just
assume that part has been said? Thanks.
I'm banging away on an OpenTrans****t-based app that needs to listen for
an incoming TCP/IP connection, accept it, and do some private-protocol
setup work on it.
I've gotten as far as the "accept" part, with everything seeming to go
according to plan, but I'm running into a question.
I'm working in "straight" C, under Carbon on MacOS 9.1, and doing the
endpoints asynchronously, with a notifier installed. The notifier
converts the OT event into an AppleEvent, and posts it to the
application event queue, where it gets dealt with at Application Event
time. (eventually - I'm aware of the possible- OK, probable - latency
issues in dealing with networking at the eventloop level) Oh, and I'm
using the "tilisten" module in the configuration string for the listener
endpoint, to serialize connection requests.
As I said, it seems to be working, as far as I've gotten. However,
there's something I don't understand, despite digging through my
"Networking with OpenTrans****t" do***entation.
Since I'm running asynch, OTAccept() is punching two notifications
through on completion - First one being "T_ACCEPTCOMPLETE", with the
listening endpoint as the cookie, being sent to the listening endpoint,
and the second one being "T_PASSCON", with the endpoint that the
connection was accepted on as the cookie, and sent to the accepting
endpoint.
There's also a caveat about how an endpoint can get a T_DATA event
before it sees the T_PASSCON, and what to do about that. I'm pretty sure
I've got that base covered.
The T__PASSCON event is obviously informational, and offers a chance for
me to hook in and do some housekeeping that needs to happen before the
endpoint truly gets put to work. A chance I take full advantage of.
What I can't figure out is how to cope with the T_ACCEPTCOMPLETE event -
It *APPEARS* to be purely informational, as far as I can figure out. Is
that figuring correct? As in, can I simply ignore it without running
into difficulty later? Or do I need to do something in response to the
T_ACCEPTCOMPLETE event? Some sort of "OK, we're done with this listen
event, go back to listening for connection requests" action I need to
take to "reset" the listener endpoint?
Any assistance/clarification appreciated.
--
Don Bruder - dakidd@[EMAIL PROTECTED]
- If your "From:" address isn't on my
whitelist,
or the subject of the message doesn't contain the exact text
"PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without
my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd>
for more
info
|
