Sharing sockets among threads

[Codeplug]

>> Just expose the data you need to your thread using a common shared pointer or a global variable

int global_data;

void foo()
{
    // access global_data
}

void bar()
{
    // access global_data
}

>> Use a critical section when reading and writting shared data [between threads].

gg

>> Codeplug: You also don't face my problem again by telling that I should pass the socket descriptor.

Since you're so good breaking things down into simple terms, perhaps you can explain how data is being "passed" to foo() and bar()?

gg

[abachler]

You can use the same socket on multiple threads. Even if SOCKET s is a local variable, you can pass s to another thread and it will still be valid. 's' is the socket identifier, not the socket itself. just like a handle, as long as the object it points to is valid, it is valid regardless of its context.

There are a few instances when having multiple threads access the same socket are useful. One is where you have sperate threads for reading and writing on the socket. Some advanced command streams may also process different types of data that get passed over a single stream. As long as each thread synchronizes its use of the socket and produces a complete frame before releasing the critical section, you will have no problems.

[Hawkin]

Codeplug: Yes sorry, I misinterpreted that.
abachler: Well, luckily the same socket can be used in different threads (not in different processes tough =/).

As I have no access to the first thread I can try to either hook the socket() function or heuristically choose the socket where to most traffic goes through (from all the sockets getpeername() returns).
I'll probably post when I come to a safe solution.

[abachler]

As I have no access to the first thread I can try to either hook the socket() function or heuristically choose the socket where to most traffic goes through (from all the sockets getpeername() returns).
I'll probably post when I come to a safe solution.

You cant access a socket owned by another process. That would be a security hole you could drive a truck through. As for not having access to the thread, you shoudl take this issue up with whoever has teh source code, adn get them to expose the SOCKET. Its kind of dangerous doing this though, as you can really scramble the data if your application isnt written to have all threads cooperate in the use fo the socket. If they do expose the socket for you, make sure there is a CRITICAL_SECTION controlling use of the socket, either one for read and one for write, or one to control both.

[abachler]

From the Visual Studio 6.0 help File -

Socket sharing between processes in Windows Sockets is implemented as follows. A source process calls WSPDuplicateSocket to obtain a special WSAPROTOCOL_INFOW structure. It uses some interprocess communications (IPC) mechanism to pass the contents of this structure to a target process. The target process then uses the WSAPROTOCOL_INFOW structure in a call to WSPSocket. The socket descriptor returned by this function will be an additional socket descriptor to an underlying socket which thus becomes shared.
It is the service provider's responsibility to perform whatever operations are needed in the source process context and to create a WSAPROTOCOL_INFOW structure that will be recognized when it subsequently appears as a parameter to WSPSocket in the target processes' context. The dwProviderReserved parameter of the WSAPROTOCOL_INFOW structure is available for the service provider's use, and may be used to store any useful context information, including a duplicated handle.
This mechanism is designed to be appropriate for both single-threaded versions of Windows (such as Windows 3.1) and preemptive multithreaded versions of Windows (such as Windows 95 and Windows NT/Windows 2000). Note however, that sockets may be shared amongst threads in a given process without using the WSPDuplicateSocket function, since a socket descriptor is valid in all of a process' threads.

So the source process must explicitly allow this behavior in order to do it. Therefor no hacking into a secure network connection from a rogue malware.