Re: socket() returning same value in shared library ( wasRe:accept() hangs)
Re: socket() returning same value in shared library ( wasRe:accept() hangs)
- Subject: Re: socket() returning same value in shared library ( wasRe:accept() hangs)
- From: Ken Baer <email@hidden>
- Date: Mon, 10 Oct 2005 17:23:25 -0700
Well, that's done the trick! I was wondering if the callback was automatically doing the accept(). The tricky part was saving away the new SOCKET that is created and handing it off to my function that was calling accept(). But, it seems to be working now. Thanks!
On Oct 10, 2005, at 1:31 PM, Douglas Davidson wrote:
On Oct 10, 2005, at 1:26 PM, Ken Baer wrote:
Also, repeating my earlier request, what is an "Accept message"?
When the Slave calls connect() (through a shared library), the Messenger callback function gets called with kCFSocketAcceptCallBack. That's what I mean by an Accept message.
Using the socket that is sent to the callback function, it then calls accept(), which hangs.
As indicated earlier in this thread, the value 42 may be a red herring.
OK, but what about the socket I am supposed to get back from accept()? It would be the same number as the listening socket.
kCFSocketAcceptCallBack has already accepted the connection for you. Look at the header comments again: "new child sockets will be accepted and passed back to the callback, with the data argument being a pointer to a CFSocketNativeHandle." The socket that is passed to you here is the new child. You don't get to accept it again. If you want to accept yourself rather than having CFSocket do it for you, you should use kCFSocketReadCallBack instead of kCFSocketAcceptCallBack.
Douglas Davidson
-Ken Baer.
Hash, Inc.
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden