Socket Server
-
Hi, I need to write a High Performance TCP/IP server for receiving the data from the GPS devices and logging it to the database for display on Google Maps. There will be thousands of GPS devices connected to the GPS server and will be transmitting the data every 30 seconds and the display will be set to refresh typically every minute. I am looking for the help in specific areas, I will write the code myself and believe me I will post the complete developed and tested code on this same forum. I understand the following challenges 1.Concurrent TCP/IP connections 2.Database table bottlenecks I would like to go for one table per device groups and different ports for devices with different protocols. I am assuming that I will need to write the following components. 1.Data Receiver 2.Parser as per the protocol and the commands 3.Data Cache 4.Database writer Receive the bytes, log the received commands to the cache, implement the lazy writer to flush the data every minute to the database using different thread. Please comments on the following. 1.Does the GPS device disconnects after sending one command or it keep the connection to send the data further like long polling? 2.Is it better idea to maintain the thread pool and keep one thread per device? How many devices can be connected simultaneously to one port? 3.If I assume that device does not disconnect the client after transmitting the bytes to the server, should I keep the channel alive on the server to keep on reading the data every 20 seconds or whenever available? 4.Is it fair enough to have the separate threads for updating the data to the database server? Say data retrieval every 20 seconds and making it persistent to the database every one minute? 5.Is there any other better protocol rather that raw TCP/IP? I guess the other protocols like http etc should be slower as the header size itself is very big. 6.What is better choice Synchronous or Asynchronous sockets? Is it feasible to use UDP? 7.What is better choice? C# and SQL Server or JAVA and mySQL on Linux? Many Thanks Vipin
Writing a high performance tcp server is very tricky. You have to have a good understanding of overlapped IO. Managing kernel receive buffers, and a huge mess of stuff that's not obvious from simple 'my first tcp server' type articles on the internet Strongly suggest you use professional messaging wrapper around tcp Eg; ZeroMQ is something that hides a lot of these details from you http://zeromq.org/[^] Another possible recommendation is WCF with the tcp binding I would not write your own tcp server just for the hell of it; it will no doubt be terrible compared to the above products Matt.
-
Writing a high performance tcp server is very tricky. You have to have a good understanding of overlapped IO. Managing kernel receive buffers, and a huge mess of stuff that's not obvious from simple 'my first tcp server' type articles on the internet Strongly suggest you use professional messaging wrapper around tcp Eg; ZeroMQ is something that hides a lot of these details from you http://zeromq.org/[^] Another possible recommendation is WCF with the tcp binding I would not write your own tcp server just for the hell of it; it will no doubt be terrible compared to the above products Matt.
-
Thanks Matt, I also thought of using WCF tcp binding but the WCF may be much slower as compare to raw sockets however dealing with raw sockets may be more tricky and challenging but still possible to implement. Thanks Vipin
WCF scales up to thousands to tens/thousands/millions messages per second It's not very likely a home grown TCP server will perform as well without years of development effort Edit (Some, not all) of the difficulty is expressed in this two parter Design and Implementation of a High-performance TCP/IP Communications Library[^] AND Design and Implementation of a High-performance TCP/IP Communications Library[^] Realistically this is only covering a small fraction of what is required though Seriously; save your self weeks/months of work and just use a library
-
WCF scales up to thousands to tens/thousands/millions messages per second It's not very likely a home grown TCP server will perform as well without years of development effort Edit (Some, not all) of the difficulty is expressed in this two parter Design and Implementation of a High-performance TCP/IP Communications Library[^] AND Design and Implementation of a High-performance TCP/IP Communications Library[^] Realistically this is only covering a small fraction of what is required though Seriously; save your self weeks/months of work and just use a library
-
Thanks Matt, I also thought of using WCF tcp binding but the WCF may be much slower as compare to raw sockets however dealing with raw sockets may be more tricky and challenging but still possible to implement. Thanks Vipin
Unless you have 5+ years experience writing high performance TCP messaging servers Your code is going to be way, way, worse than what's in WCF and not as scalable. Unless you know how TCP buffers are managed by the kernel; why it's bad to use thread-per request; what overlapped IO is and what an NT fiber is Then you're 0% the way qualified to write your own TCP server and shouldn't even attempt it. Writing a high performance 'good' tcp server implementation is 1 to 5 years development effort on its own. You can write a raw sockets server using a thread-per-request model in like a few hours Sure; But you'll start running into issues with many clients pretty rapidly. If you want to reduce the packet size of WCF. Use google protobuff binding for WCF. It makes insanely tiny packets. There's really no need to cause some other poor developer to work on a naive server implementation when there are very fast and very scaleable tools (WCF, ZeroMQ) that take care of all of this for you Writing a custom tcp server is pretty much like going "I'd like to write my own kernel scheduler" It's easy to get going, takes a lifetime to do it right though. That's why ZeroMQ and WCF exist.
-
Hi, I need to write a High Performance TCP/IP server for receiving the data from the GPS devices and logging it to the database for display on Google Maps. There will be thousands of GPS devices connected to the GPS server and will be transmitting the data every 30 seconds and the display will be set to refresh typically every minute. I am looking for the help in specific areas, I will write the code myself and believe me I will post the complete developed and tested code on this same forum. I understand the following challenges 1.Concurrent TCP/IP connections 2.Database table bottlenecks I would like to go for one table per device groups and different ports for devices with different protocols. I am assuming that I will need to write the following components. 1.Data Receiver 2.Parser as per the protocol and the commands 3.Data Cache 4.Database writer Receive the bytes, log the received commands to the cache, implement the lazy writer to flush the data every minute to the database using different thread. Please comments on the following. 1.Does the GPS device disconnects after sending one command or it keep the connection to send the data further like long polling? 2.Is it better idea to maintain the thread pool and keep one thread per device? How many devices can be connected simultaneously to one port? 3.If I assume that device does not disconnect the client after transmitting the bytes to the server, should I keep the channel alive on the server to keep on reading the data every 20 seconds or whenever available? 4.Is it fair enough to have the separate threads for updating the data to the database server? Say data retrieval every 20 seconds and making it persistent to the database every one minute? 5.Is there any other better protocol rather that raw TCP/IP? I guess the other protocols like http etc should be slower as the header size itself is very big. 6.What is better choice Synchronous or Asynchronous sockets? Is it feasible to use UDP? 7.What is better choice? C# and SQL Server or JAVA and mySQL on Linux? Many Thanks Vipin
You seem to concentrate on the data collection side only. You also said: "the display will be set to refresh typically every minute". Ehm, where? How many "display" clients? Webbrowser? And which data are to be displayed? The current location of thousands of devices?? The path taken by a selected device during the last timespan? This involves querying data from the database, and perhaps also some calculations on the data in the database. Or additionally some calculations on the data received from the database in an application...
-
Hi, I need to write a High Performance TCP/IP server for receiving the data from the GPS devices and logging it to the database for display on Google Maps. There will be thousands of GPS devices connected to the GPS server and will be transmitting the data every 30 seconds and the display will be set to refresh typically every minute. I am looking for the help in specific areas, I will write the code myself and believe me I will post the complete developed and tested code on this same forum. I understand the following challenges 1.Concurrent TCP/IP connections 2.Database table bottlenecks I would like to go for one table per device groups and different ports for devices with different protocols. I am assuming that I will need to write the following components. 1.Data Receiver 2.Parser as per the protocol and the commands 3.Data Cache 4.Database writer Receive the bytes, log the received commands to the cache, implement the lazy writer to flush the data every minute to the database using different thread. Please comments on the following. 1.Does the GPS device disconnects after sending one command or it keep the connection to send the data further like long polling? 2.Is it better idea to maintain the thread pool and keep one thread per device? How many devices can be connected simultaneously to one port? 3.If I assume that device does not disconnect the client after transmitting the bytes to the server, should I keep the channel alive on the server to keep on reading the data every 20 seconds or whenever available? 4.Is it fair enough to have the separate threads for updating the data to the database server? Say data retrieval every 20 seconds and making it persistent to the database every one minute? 5.Is there any other better protocol rather that raw TCP/IP? I guess the other protocols like http etc should be slower as the header size itself is very big. 6.What is better choice Synchronous or Asynchronous sockets? Is it feasible to use UDP? 7.What is better choice? C# and SQL Server or JAVA and mySQL on Linux? Many Thanks Vipin
Interesting question. Firstly, I think you need to be sure on how each GPS would connect. You suggest TCP, you need to get this confirmed and you need to find out whether it connects, delivers its information then disconnects (likely) or it leaves the connection open (unlikely). How many GPS units are you talking about, how many thousand? If it's a thousand, and they update twice a minute you're only looking at 33 connections/second which I don't find in any way scary. From what I know about GPSs (which isn't a great deal) they normally send a very small packet just containing location information. Then I'd implement a producer-consumer queue. Each incoming connection takes the data and just sticks it on the queue and disconnects. On the other end you have something (or more than one) which pulls these off the queue and writes them to the database. I'd go for asynchronous constructs (BeginAccept, BeginReceive) on the reception end as these won't require a long running thread and scale well.
Regards, Rob Philpott.
-
You seem to concentrate on the data collection side only. You also said: "the display will be set to refresh typically every minute". Ehm, where? How many "display" clients? Webbrowser? And which data are to be displayed? The current location of thousands of devices?? The path taken by a selected device during the last timespan? This involves querying data from the database, and perhaps also some calculations on the data in the database. Or additionally some calculations on the data received from the database in an application...
Thanks Bernhard The display will be the browser and typically one user for every 30 devices. Which most of the time will display the last stats of the device. I think we can store the last positions and other states in a separate table. Or some mechanism can be developed that can provide the data of current stats to the browser without hitting the database. The devices will be 2000 and will be transmitting the data every 20 seconds. On a maximum there can be 60000,000,00 records in the transaction table. Which SQL Sever can manager easily without loosing the performance.
-
Unless you have 5+ years experience writing high performance TCP messaging servers Your code is going to be way, way, worse than what's in WCF and not as scalable. Unless you know how TCP buffers are managed by the kernel; why it's bad to use thread-per request; what overlapped IO is and what an NT fiber is Then you're 0% the way qualified to write your own TCP server and shouldn't even attempt it. Writing a high performance 'good' tcp server implementation is 1 to 5 years development effort on its own. You can write a raw sockets server using a thread-per-request model in like a few hours Sure; But you'll start running into issues with many clients pretty rapidly. If you want to reduce the packet size of WCF. Use google protobuff binding for WCF. It makes insanely tiny packets. There's really no need to cause some other poor developer to work on a naive server implementation when there are very fast and very scaleable tools (WCF, ZeroMQ) that take care of all of this for you Writing a custom tcp server is pretty much like going "I'd like to write my own kernel scheduler" It's easy to get going, takes a lifetime to do it right though. That's why ZeroMQ and WCF exist.
Thanks Matty If we use the WCF, i guess it would not be able to communicate with the RAW tcp client, we will need to write some code for WCF layer to make it communicating with the RAW tcp connections. Thanks for suggesting the ZeroMQ, i will explore these libraries and will let you know.
-
Thanks Matty If we use the WCF, i guess it would not be able to communicate with the RAW tcp client, we will need to write some code for WCF layer to make it communicating with the RAW tcp connections. Thanks for suggesting the ZeroMQ, i will explore these libraries and will let you know.
What raw tcp client? The GPS device is accessed via TCP out of the box? Not USB or RS232 or something? WCF supports TCP out of the box; you don't need to write any code http://msdn.microsoft.com/en-us/library/system.servicemodel.nettcpbinding%28v=vs.110%29.aspx[^]