Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / December 2007

Tip: Looking for answers? Try searching our database.

UDP Server scalability question

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Ron Skufca - 27 Dec 2007 02:38 GMT
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
Peter Duniho - 27 Dec 2007 03:20 GMT
> [...]
> 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
[quoted text clipped - 3 lines]
>
> 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
Ron Skufca - 27 Dec 2007 13:33 GMT
> > [...]
> > My initial thought was to spawn a thread to handle the parsing/inserting  
[quoted text clipped - 36 lines]
>
> 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.

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.