Multi-threaded P2P UDP Asynchronous example
Rehmet
Is there anyone can help me on how to build Multi-Threaded P2P UDP
Asynchronous for 5 clients? It needs to be multi-threaded because it
needs to send video and audio.
Peter Duniho
> Is there anyone can help me on how to build Multi-Threaded P2P UDP
> Asynchronous for 5 clients?
No doubt people who follow this newsgroup, or the alt.winsock.programming
newsgroup, both of which have very little traffic lately but which
probably still have some people who still subscribe, are willing to answer
specific questions that may come up as you work on your project.
As far as the problem statement so far, it's way too vague for anyone to
offer with a useful reply suitable in the context of a Usenet newsgroup.
Other than to say, "probably, yes". :)
> It needs to be multi-threaded because it
> needs to send video and audio.
While being able to implement the solution using threads at some level may
well turn out to be useful, the kind of data you're sending doesn't in any
way mandate a need to be multi-threaded, and with only 5 clients I suspect
that at least some of the non-threaded paradigms in Winsock would work
fine.
Pete
Rehmet
> newsgroup, both of which have very little traffic lately but which
> probably still have some people who still subscribe, are willing to answer
> specific questions that may come up as you work on your project.
Too many spams in this group? can you kick the spammers out?
> As far as the problem statement so far, it's way too vague for anyone to
> offer with a useful reply suitable in the context of a Usenet newsgroup.
> Other than to say, "probably, yes". :)
> While being able to implement the solution using threads at some level may
> well turn out to be useful, the kind of data you're sending doesn't in any
> way mandate a need to be multi-threaded, and with only 5 clients I suspect
> that at least some of the non-threaded paradigms in Winsock would work
> fine.
>
> Pete
Oh why is that Pete? is there any reason for that? I suppose multi-
threading can give you more robust code and hold client list far
better than using CPtrList.
Thanks.
Peter Duniho
>> No doubt people who follow this newsgroup, or the
>> alt.winsock.programming
>> newsgroup, both of which have very little traffic lately but which
>> probably still have some people who still subscribe, are willing to
>> answer
>> specific questions that may come up as you work on your project.
>
> Too many spams in this group? can you kick the spammers out?
Are you suggesting a hypothesis for the relatively low traffic?
I have not seem much evidence of spamming in either newsgroup. I think
that the relatively low traffic is due primarily to the fact that Winsock
is not the API of choice for most people new to network programming on
Windows. Higher-level APIs such as found in .NET and Java offer similar
functionality, but in the context of a framework with broader support for
a wide variety of application needs.
I'm sure there are lots of people still using Winsock, but I would guess
that by and large they are people working on "legacy" applicatons, or at
least people who are already very familiar and more comfortable with the
basic Win32 API, including Winsock. Those people by and large probably
don't see a need to solicit advice in these newsgroups, since they are
already experts in their field. However, they may still be monitoring the
newsgroup and may be available should a question come up.
Note that as far as Winsock goes, I am _not_ an expert in that field. :)
But I know enough about Winsock to answer the occasional question and the
traffic in the Winsock newsgroup is so low there's just no real reason to
not continue monitoring them. :)
>> While being able to implement the solution using threads at some level
>> may
>> well turn out to be useful, the kind of data you're sending doesn't in
>> any
>> way mandate a need to be multi-threaded, and with only 5 clients I
>> suspect
>> that at least some of the non-threaded paradigms in Winsock would work
>> fine.
>>
>> Pete
>
> Oh why is that Pete? is there any reason for that? I suppose multi-
> threading can give you more robust code and hold client list far
> better than using CPtrList.
"Oh why" is what? Why could multi-threading be useful? Or why isn't
multi-threaded code needed to support a video or audio data stream? And
what does "CPtrList" have anything to do with whether you are writing
multi-threaded code or not?
Multi-threaded code can be more complex. It can simply one aspect of the
architecture, which can in fact improve reliability, but it can at the
same time complicate other aspects of the architecture, which can lead to
a new class of bugs.
If you can architect your design such that none of the threads ever need
to interact with each other, or share any data, then a multi-threaded
design can have some benefit without suffering any of the usual
multi-threading pitfalls. But that's a rare situation.
As far as the performance goes, badly written multi-threaded code can
perform _worse_ than single-threaded code. But more importantly, the
kinds of bottlenecks that may come up with respect to network i/o have
more to do with scalability of your i/o with respect to the number of
connections/clients. Even if one assumes that the code is written
correctly, for dealing with a relatively low number of clients,
single-threaded code should be able to manage just fine.
Why do YOU believe that you need to write multi-threaded code? And I mean
more than just the fact that you intend to send video and audio data. WHY
does sending video and audio data imply to you that you need
multi-threaded code?
Pete
Rehmet
>
> I have not seem much evidence of spamming in either newsgroup. I think
> that the relatively low traffic is due primarily to the fact that Winsock
> is not the API of choice for most people new to network programming on
> Windows. Higher-level APIs such as found in .NET and Java offer similar
> functionality, but in the context of a framework with broader support for
> a wide variety of application needs.
>
> I'm sure there are lots of people still using Winsock, but I would guess
> that by and large they are people working on "legacy" applicatons, or at
> least people who are already very familiar and more comfortable with the
> basic Win32 API, including Winsock. Those people by and large probably
> don't see a need to solicit advice in these newsgroups, since they are
> already experts in their field. However, they may still be monitoring the
> newsgroup and may be available should a question come up.
>
> Note that as far as Winsock goes, I am _not_ an expert in that field. :)
> But I know enough about Winsock to answer the occasional question and the
> traffic in the Winsock newsgroup is so low there's just no real reason to
> not continue monitoring them. :)
Yeah, probably true, I am using CSocket for MFC, but people in MFC
forum told me to use Winsock for better deal or at least CAsyncSocket.
Pete, I have this question in my mind, that decoder would take time to
decode every incoming frame and while one remote computer is still
decoding, the other will wait (network blocked), therefore, you'll
have a lagging problem in some of the remote computer( if your have 5,
especially). And this is with UDP data packet. So, the real question
is whether the network need to wait for that decoding function gives
return value or not. If, yes, how to make the network not to wait for
return value, hence, sending other remote computers without no halt.
I am thinking my multi-threading need not to communicate with other
threads, so, I am trying to utilize its parallelism advantage.
>But more importantly, the
> kinds of bottlenecks that may come up with respect to network i/o have
> more to do with scalability of your i/o with respect to the number of
> connections/clients.
Pete, can you explain more on what do you mean by this?
Peter Duniho
> [...]
>> Why do YOU believe that you need to write multi-threaded code? And I
>> mean
>> more than just the fact that you intend to send video and audio data.
>> WHY
>> does sending video and audio data imply to you that you need
>> multi-threaded code?
>
> Pete, I have this question in my mind, that decoder would take time to
> decode every incoming frame and while one remote computer is still
> decoding, the other will wait (network blocked), therefore, you'll
> have a lagging problem in some of the remote computer( if your have 5,
> especially). And this is with UDP data packet.
With UDP, the sending computer never waits for the receiving computer.
Datagrams might be dropped, but for streaming video that might actually be
desirable. After all, why waste time trying to buffer data that the
receiving computer isn't fast enough to deal with anyway?
With TCP, it's true...the sender may wind up having to wait on the
receiver. But again, for streaming video if the receiver is not decoding
the data fast enough to keep up with the network stream, something's got
to give anyway. Assuming the video needs to be presented in real time
(which is always going to be true for streaming video), you can't let the
receiver decode every byte that gets streamed unless it can do that faster
than the data is being streamed.
In other words, in neither case is it actually a problem that is
resolveable simply by switching to multi-threaded code.
There are good reasons to have multi-threaded network i/o code, but the
mere fact that you might be streaming video and audio data isn't one of
them.
> [...]
>> But more importantly, the
>> kinds of bottlenecks that may come up with respect to network i/o have
>> more to do with scalability of your i/o with respect to the number of
>> connections/clients.
>
> Pete, can you explain more on what do you mean by this?
Various i/o mechanisms in Winsock have different limitations.
Thread-per-connection implementations run into the cost of a thread on
Windows (32-bit Windows is limited to roughly 2000 threads, and
performance will suffer significantly well before that point).
Event-driven (WSAEventSelect) and window message-driven (WSAAsyncSelect)
run into limitations with respect to how many event handles you can wait
for at once, and how many window messages you can define. The
least-limited i/o mechanism you can use with Winsock is i/o completion
ports.
If you only have a peer-to-peer arrangement, then it's possible none of
these things would ever matter. But they still remain the more
significant bottleneck in terms of what you might be concerned with. The
kind of data you're sending doesn't really affect what i/o mechanism you
choose, at least not from a performance point of view.
Pete