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 13:26:36 -0700
On Oct 10, 2005, at 11:54 AM, Justin C. Walker wrote:
On Oct 10, 2005, at 11:29 , Ken Baer wrote:
I am porting a suite of WinSock based applications. We are using a
socket wrapper class that is in a shared Dynamic library. Right
now the server is running on a PC, but the Messenger and Slave are
running on a Mac (at the same time). The Messenger talks to the
server, and passes information back and forth between the Server
and the Slave. Messenger and Slave are sharing the same dynamic
library that makes all the calls to BSD socket functions.
I think the reason that the call to accept() called from the
Messenger is that the SOCKET value is the same from the listening
socket on the Messenger and the messenger socket that the Slave
tries to connect with. What's happening is that the BSD function
socket() is returning the same value (42) in the same dynamic
library when called from 2 different applications. They are booth
open.
Is there a way to insure that socket() returns a unique number in a
shared library environment?
I'm not sure I understand this. You initially said that your server
is hanging in accept(). Now, it sounds like the "Messenger", on a
different machine from the server, is doing an accept. Is that correct?
In my first message I was trying to simplify it by only talking about Messenger and Slave, where the problem is. There are 3 applications, one on the PC which is Server, and Messenger and Slave that are running on the same Mac. Messenger acts as a conduit between Server and Slave.
Can you be clearer about what processes (not threads) run where,
which process is hanging in accept(), and which processes are talking
to which?
Server is running on the PC. I launch Messenger on the Mac, and it connects to the Server. It then gets a message from the Server to launch the Slave. It creates a listening socket to listen for the Slave and installs a callback function using
CFSocketCreateRunLoopSource() with
kCFSocketAcceptCallBack | kCFSocketWriteCallBack | kCFSocketConnectCallBack and then calls listen(), and then launches the Slave. The Slave creates a messenger socket and installs a callback function with
kCFSocketReadCallBack | kCFSocketWriteCallBack | kCFSocketConnectCallBack and calls connect().
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.
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for General Semantics
--------
"Weaseling out of things is what separates us from the animals.
Well, except the weasel."
- Homer J Simpson
--------
_______________________________________________
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
-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