Re: UDP server scalability question
- From: "Cowboy \(Gregory A. Beamer\)" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 2 May 2006 07:27:40 -0500
First, what is the load you are expecting? Unless it is rather high,
offloading work is just extra code. And, spinning up threads can be
problematic, esp. if more than one thread can contend for the same resource.
Best to keep it simple until you need the extra
Second, why are you setting up an ACK on UDP? If simply to give something
back and then work, there is not an issue. If you are attempting to add
reliability ... that is another story. UDP is meant to be a fast, yet
unreliable, protocol. It is best for streaming and other types of uses that
do not require reliability of every packet. If you ACKing is designed to add
reliability, you are better served using TCP, as it is a reliable transport.
Why create your own reliability mechanism, which is likely to be slow, when
TCP has one built in for you?
If this is all the server does, spawning multiple threads will most likely
just add complexity to the application. Multiple threads are useful when
there is long running work that can be done in parallel.
As for the BeginReceive versus buffer, a buffer should slow down delays as
long as you are not attempting to introduce reliability. If the client
continues to ask for packets, you will have a bottleneck. The asynch comes
into play more when you are dealing with spawning up threads, which I am not
fully convinced you need to do.
Many of the questions you have asked require additional details, as UDP,
itself, is not a given, esp. if you wish a reliable transport (sounding like
a broken record? :-)). Depending on how quickly you start streaming out
bytes, the ACK may be extra work that is unnecessary (getting bytes back is
an ACK, of sorts ;->). Unless the ACK is giving data (what the client should
expect, for example), which makes it more than a simple ACK, it may simply
add more steps to the process. I also question why the client needs to ACK
back, except for reliability (yeah, broken record), which is better served
with TCP.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
"andrew queisser" <andrewdotqueisser@xxxxxx> wrote in message
news:0Mr5g.7022$P55.4739@xxxxxxxxxxxxxxxxxxx
I've got the following situation and I'm wondering about scalability of
different solutions:
1) Client sends a request to a fixed port on a UDP server
2) UDP server sends an ACK and launches the request (worker thread)
3) UDP server sends response data back to client
4) Client sends ACK back to server
My question is about how to distribute the work among the main server and
the worker threads. My initial solution is to have the client send
everything to the fixed UDP port and then have the main server thread
filter out duplicate requests and duplicate ACKs. The server thread also
sends the response from step 2). The worker thread would only send the
response back to the client via a socket that each worker thread opens up
upon creation.
However, I could also have the worker thread execute steps 2), 3) and
receive the ACK from step 4). That would relieve some load from the main
server thread, especially matching up the ACK with the thread that's
handling the request.
On the other hand, everything has to go through one network interface
anyway, so is there some advantage of structuring the code one way or the
other?
Also, does it make sense to use asynchronous BeginReceiveFrom with UDP in
order to get back to reading the socket or is the buffering on the
incoming UDP socket flexible enough to buffer out reasonable delays in the
main thread?
Thanks,
Andrew
.
- Follow-Ups:
- Re: UDP server scalability question
- From: andrew queisser
- Re: UDP server scalability question
- References:
- UDP server scalability question
- From: andrew queisser
- UDP server scalability question
- Prev by Date: Re: How to create a custom prerequisite VB.NET 2005
- Next by Date: Re: dll hell
- Previous by thread: UDP server scalability question
- Next by thread: Re: UDP server scalability question
- Index(es):
Relevant Pages
|