Jump to content

  • Log In with Google      Sign In   
  • Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

#Actualrip-off

Posted 03 January 2012 - 05:33 AM

I don't believe your approach will work. WSADuplicateSocket is intended for socket handoff, not socket sharing:

The descriptors that reference a shared socket can be used independently for I/O. However, the Windows Sockets interface does not implement any type of access control, so it is up to the processes involved to coordinate their operations on a shared socket. Shared sockets are typically used to having one process that is responsible for creating sockets and establishing connections, and other processes that are responsible for information exchange.

Maybe this is what you want to do?

If not, a simple solution to the original problem to that is to to have the secondary servers connect to the primary one, and have the primary one demultiplex the data as it comes in (however you propose to handle that) and copy it to the correct "local" connection to the secondary server.

One approach might be for the secondary server to connect to the problematic socket, and identify itself as a server somehow. The primary server would echo data back out that socket when it is intended for this sub-server. Another might use a local IPC mechanism, like a named pipe, to connect to the primary server, not unlike what you were trying to do with the socket description, but with the actual data instead.

That said, this is still highly unusual. Multiplexing connections like that is generally handled at a different level (e.g. a SSH tunnel), if it is indeed necessary at all.

#1rip-off

Posted 03 January 2012 - 05:30 AM

I don't believe your approach will work. WSADuplicateSocket is intended for socket handoff, not socket sharing:

The descriptors that reference a shared socket can be used independently for I/O. However, the Windows Sockets interface does not implement any type of access control, so it is up to the processes involved to coordinate their operations on a shared socket. Shared sockets are typically used to having one process that is responsible for creating sockets and establishing connections, and other processes that are responsible for information exchange.


The simple solution to that is to to have the other servers connect to the first one, and have the first one demultiplex the data as it comes in (however you propose to handle that) over this connection.

One approach might be to connect to the problematic socket, and identify itself as a server somehow. The main host would copy data intended for this sub-server. Another might use a local IPC mechanism, like a named pipe, to connect to the main host. Again, the data can be copied down the pipe.

That said, this is still highly unusual. Multiplexing connections like that is generally handled at a different level (e.g. a SSH tunnel), if it is indeed necessary at all.

PARTNERS