UDP Server scalability question

I am implementing a UDP server to retrieve and process GPS coordinates from a
client application installed in various vehicles. Right now there are around
10 UDP clients sending data with that figure expected to grow to hundreds in
the future. The basic architecture is as follows:

1.) Client sends UDP position message (around 100 ASCII chars) about 1 per
sec to a predefined port.
2.) UDP server is listening on predefined port with the Socket.ReceiveFrom
method.
3.) When UDP server receives message it fires an event to process the message.

Part 1, 2 and 3 are implemented and seem to be working fine in a test
environment. My question is the best way to handle the following.

3.) Parse the message and create a valid SQL Insert or update statement to
insert into an SQL Server 2005 database.

My initial thought was to spawn a thread to handle the parsing/inserting of
the incoming messages, but with messages streaming in continusously I don't
think this would be the best way.

My other idea which i don't have much experience with is to create a queue
and stick each incoming message in the queue and have another thread handle
retrieving the messages from the queue and doing the SQL insert/update.

What would be the pros and cons of using the queue?

Also are there any other patters that might be helpful in this situation
that I can research.

Thanks,

Ron

On Wed, 26 Dec 2007 18:38:00 -0800, Ron Skufca <Ron
<Skufca (AT) discussions (DOT) microsoft.com>> wrote:

[...]
My initial thought was to spawn a thread to handle the parsing/inserting
of
the incoming messages, but with messages streaming in continusously I
don't
think this would be the best way.

Do you mean start a new thread for each message received? If so, yes...I
agree this wouldn't be the best way, or even a very good way.

My other idea which i don't have much experience with is to create a
queue
and stick each incoming message in the queue and have another thread
handle
retrieving the messages from the queue and doing the SQL insert/update.

What would be the pros and cons of using the queue?

I can't think of any real con per se. It's potentially more complicated,
but not much and it's a fairly common and natural solution to the problem
you're describing. See "producer/consumer". Producer would be the code
recieving datagrams, consumer would be the code handling the thread doing
the SQL operations.

Assuming that a single SQL operation can be faster than a single UDP
datagram can be received, this should work fine. If not, then you have a
problem, as the consumer thread won't be able to keep up with the
producer. You'll either need to know you have moments when you can catch
up, or you need to be able to discard datagrams, or you need to speed the
SQL operations up.

If the latter is necessary, it seems likely to me that you could improve
performance by consolidating your SQL operations. Presumably most of the
overhead comes from moving data over the SQL server connection and any
latency in the server's response. If you have a way to do a single SQL
operation that handles data from multiple datagrams, that could improve
performance enough that the consumer thread can easily outpace the
producer.

Pete

"Peter Duniho" wrote:

On Wed, 26 Dec 2007 18:38:00 -0800, Ron Skufca <Ron
Skufca (AT) discussions (DOT) microsoft.com>> wrote:

[...]
My initial thought was to spawn a thread to handle the parsing/inserting
of
the incoming messages, but with messages streaming in continusously I
don't
think this would be the best way.

Do you mean start a new thread for each message received? If so, yes...I
agree this wouldn't be the best way, or even a very good way.

My other idea which i don't have much experience with is to create a
queue
and stick each incoming message in the queue and have another thread
handle
retrieving the messages from the queue and doing the SQL insert/update.

What would be the pros and cons of using the queue?

I can't think of any real con per se. It's potentially more complicated,
but not much and it's a fairly common and natural solution to the problem
you're describing. See "producer/consumer". Producer would be the code
recieving datagrams, consumer would be the code handling the thread doing
the SQL operations.

Assuming that a single SQL operation can be faster than a single UDP
datagram can be received, this should work fine. If not, then you have a
problem, as the consumer thread won't be able to keep up with the
producer. You'll either need to know you have moments when you can catch
up, or you need to be able to discard datagrams, or you need to speed the
SQL operations up.

If the latter is necessary, it seems likely to me that you could improve
performance by consolidating your SQL operations. Presumably most of the
overhead comes from moving data over the SQL server connection and any
latency in the server's response. If you have a way to do a single SQL
operation that handles data from multiple datagrams, that could improve
performance enough that the consumer thread can easily outpace the
producer.

Pete

Thanks for the info it was very helpful.

I believe as more vehicles come on line that the consumer might encounter
difficulty keeping up with the producer. I will explore having the consumer
do multiple inserts at once.