Hi again :)
I'll just drop the question: Can I get a socket (number) in another thread if I don't pass it when creating the thread? Like with a function or a procedure?
Tia, Hawk
Printable View
Hi again :)
I'll just drop the question: Can I get a socket (number) in another thread if I don't pass it when creating the thread? Like with a function or a procedure?
Tia, Hawk
Yes. You just need to use proper synchronization when sharing variables amoung threads.
gg
And of course, you don't want to go reading one socket from more than one thread, whatever you do. Writing to the same socket from multiple threads will also be hard to make work [although possibly a little more manageable, as you at least have some control over what is going on].
--
Mats
Oh I mean when the socket variable in thread A is a local variable.Quote:
Originally Posted by Codeplug
I really want to test that out. As for send()ing, after tests I know that I can send from both threads if I let thread B know the socket from thread A.Quote:
Originally Posted by matsp
Sure, you CAN call send from multiple threads, but the result will not be "useful".
Imagine you are sending the two strings:
"Hello World"
"Hi Universe"
Now, you may end up with:
"Hello World", "Hi Universe",
or
"Hi Universe", "Hello World"
or
"HHiell oUnWoivrldrse"
Or just about any other combination of those two strings, depending on what the specific implementation of send does in your system.
What, exactly do you think you would achieve by using two threads on the same socket?
--
Mats
What about
InitializeCriticalSection()
TryEnterCriticalSection()
LeaveCriticalSection()
DeleteCriticalSection()
Yes, that would work, but then what is the benefit of using multiple threads? You don't actually gain anything if you are sitting around waiting for the other thread to finish sending/receiving something...Quote:
Originally Posted by Hawkin
Of course, if sending to the socket is only a tiny part of the overall work of the thread, but if that's the case, I would rather see a design where one thread is responsible for sending the data out, and one or more threads "doing work" - that way, you can (hopefully) continue working in the worker thread, whilst the "send" thread is sending the message. Even if you can't, it's a simple wait for the send complete event before you continue, so no need for rather clumsy critical sections, but a traditional request/wait pair.
--
Mats
Maybe I can't follow your last post, but you said threaded send()s would cause mixed strings on the same socket as it would happen with printf()ing with 2 or more threads on the same stream. I have not tested if it would really mix it up but nevertheless with critical sections I can avoid stuff that could happen.
And both threads should send() data.
After further researches I found a way which finds the connected socket which I want to find. With this way I can only find all connected sockets and I can't distinguish between them if there are more than 1 connected sockets.
With a getpeername() loop I check all sockets from within a acceptable range.
I am surprised tough! If I create a program which connects only once to a server, say on socket 96, getpeername() also finds socket 97 and socket 98 as connected ones :o
Also I can send on either 96, 97 or 98 just fine.
Why's that? And is there a better method than with getpeername()?
Don't loop on getpeername(). Just expose the data you need to your thread using a common shared pointer or a global variable. Use a critical section when reading and writting shared data.
gg
It works, why shouldn't I use it? From the beginning I said I won't pass the socket descriptor, that's why I am having a problem and create this thread in the forums. If I passed it from the beginning I'd not have gotten into that topic and I had not learned anything, but now I know that there is getpeername() and how it works.
Also I learned about critical sections.
Also I found out that if I connect through 1 socket, I open 3 instead (which I still don't know why yet).
That is what "pro coders" don't seem to get. I always get labled with "You don't need to because there is standardized stuff" or "Don't do that because it means some little extra work for you", maybe just because they don't know how to help? Or do they want to look down on me by telling me I shouldn't think of alternatives and try out new stuff? Or don't they want to help even if they knew how?
Please let me know, I am dying to know about this... people keep doing it for years.
That's what I've asked but as stated in the first post this sentence interpretatively means "are there better methods but passing the socket descriptor?"Quote:
And is there a better method than with getpeername()?
Please tell me why are you trying to lead me in another way rather than trying to help me reaching my goal?
What is your goal? If we know where you are heading, we can probably help you better, than if you ask questions about details of things: Asking "How do I remove a wheelnut?" or asking "How do I fix a flat tyre?" - which do you think will get your flat tyre fixed quicker? In your case you are asking if you can use send on multiple sockets, and I say that it is risky, and just because it happens to work on your system right now, doesn't mean that it's guaranteed to work on other systems.
Yes, you can avoid thread-unsafe code by using critical sections - but the problem is that only one thread is allowed to run inside a critical section, so if you spend most of your time in your multiple threads inside the critical section (or waiting for the critical section) then the result is essentially the same as single threaded application, but with more overhead for handling the switching between threads and the critical section locking/unlocking - so you haven't actually gained anything.
If on the other hand you are spending very little time sending through your socket, you probably should make the send call in another thread, and let the "work" threads do whatever calculations or similar that they do - this will help you get MORE work done, whilst the sending data thread is just sitting there waiting for more data to send most of the time.
If your socket is actually connecting to a network [rather than internally within a single machine] then the slowest part of the transmission will be outside your machine, and no matter how many threads you have trying to pump data out of the machine, you will not achieve more than what your current network capacity is - in machines that doesn't have 10Gb/s network (or faster), this is normally done by a single thread on a machine with more than about 500MHz x86 processor.
--
Mats
>> Just expose the data you need to your thread using a common shared pointer or a global variable
>> Use a critical section when reading and writting shared data [between threads].Code:int global_data;
void foo()
{
// access global_data
}
void bar()
{
// access global_data
}
gg
Just now I think I have reached nothing with my previous post - I appreciate that you guys spend your time trying to help me, but still you didn't touch the actual problem.
I already specified that in the first post, here's a list if you can't tell from post1:Quote:
Originally Posted by matsp
- I have one process.
- I have two threads.
- Thread1 is connected to anywhere.
- Thread1 is only connected once.
- Thread1 knows its socket descriptor but saved it in a local variable.
- Thread2 needs to know on which socket descriptor Thread1 is connected on.
- Thread2 has been created with no arguments.
Maybe it's nice information if you talk about network speed or that my program will be that fast or that fast depending on how I use critical sections or that I "don't gain anything". <- This doesn't matter because the actual problem needs to be solved.
You are going around my problem (again), and solving it IS my goal.
Now I told you my goal (again), please take into account that only and really only this matters, other stuff is totally irrelevant as long as the main problem has not been solved.
Codeplug: You also don't face my problem again by telling that I should pass the socket descriptor.
I will stick with getpeername() if this doesn't lead to a solution. But thanks anyways for your time.
on windows - if you have a message queue on the second thread - you can use PostThreadMessage from the first thread to the second thread with the address of the variable
Well, I'm concerned with the OVERALL problem, not transferring a handle/descriptor from one thread to another. If that's all you want to do, multiple suggestions have been made, including "using a global variable" - combine that with a suitable event/mutex/critsection to prevent problems with multiple threads.
--
Mats
>> Codeplug: You also don't face my problem again by telling that I should pass the socket descriptor.Quote:
Originally Posted by Codeplug
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
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.
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.
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.Quote:
Originally Posted by Hawkin
From the Visual Studio 6.0 help File -
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.Quote:
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.