0

We are designing a Mutliple Client-Server Model for The Server is supposed to :

  1. Transfer the configuration file (size of 2000Kb) to client
  2. Send the UDP/TCP port information for further communication
  3. Receive the statistical data back from the client every 2 second

We are planning for using UDP (mainly due to speed).
I am looking forward for some design options using UDP and suggestions related how to go about with the implementation.

simonc
  • 41,632
  • 12
  • 85
  • 103
user1649761
  • 11
  • 1
  • 1
    How many simultaneous clients? Read about the [C10K problem](http://en.wikipedia.org/wiki/C10k_problem)! I am not sure you really need to use UDP... – Basile Starynkevitch Aug 30 '13 at 12:12
  • 2
    How critical is the statistical information ? Can you go with a missing message once in a while ? Can you go with a garbled one ? – cnicutar Aug 30 '13 at 12:12
  • 2
    Any specific question you're having? – Carsten Aug 30 '13 at 12:12
  • Basile Starynkevitch: We will be having Max of 16 simultaneous client. - AB – user1649761 Aug 30 '13 at 12:32
  • Basically we will be designing a monitoring tool, so the statistical information is of high importance. Client needs to send the statistical information every 2 second - AB – user1649761 Aug 30 '13 at 12:35
  • 1
    Are all the clients on the same network as the server? Or are there many networks in between? – Some programmer dude Aug 30 '13 at 12:38
  • 1
    With a few dozens of simultaneous clients, I would use TCP (and perhaps even also HTTP) ... UDP is very probably not worth the burden (you may end up re-implementing -in your application- on UDP many of the features given by TCP) – Basile Starynkevitch Aug 30 '13 at 12:41
  • Clients and Servers will be on different network (Network-1 (clients) ===== Server (Network-2) -AB – user1649761 Aug 30 '13 at 12:42
  • You might also want to edit in some details about the nature of the data. Eg. is it important where exactly it came from, or what order you receive and process it in? – CodeClown42 Aug 30 '13 at 13:08
  • Note that using UDP over the Internet can be difficult, since many (most?) clients are behind NAT and/or firewalls that filter out incoming UDP packets. There are techniques like "hole punching" that can be used to get around that, but they are non-obvious and don't work in all situations. It's often easier to just use TCP, since just about everyone can make a TCP connection from their home machine to a server on the Internet. (The server typically can't make a TCP connection to the client though!) – Jeremy Friesner Aug 30 '13 at 15:34
  • I don't believe SO is a place to look for proposals of designs... – zoska Sep 02 '13 at 15:27

1 Answers1

3

using UDP (mainly due to speed)

== poor decision making in this case. Let's consider some of the reasons UDP might be considered faster in relation to what you are doing, and the constraints that UDP imposes vs. TCP.

UDP is, in some cases, in theory, faster because it saves a bit on some [blah blah] IP level stuff. Great. However, you get what you pay for, and a couple of things you don't pay for with UDP are:

  1. A persistent connection.

  2. A consistent connection (i.e, one in which information arrives in the order in which it was sent).

But based on your spec, it seems to me you need both of those, so you are going to have to pay for them some other way.

You need #1 because you are accepting a continuing stream of data from a specific source. Using TCP, this is very straightforward: the client connects and starts sending. Using UDP, there is no continuing server<->client relationship, so the only way to decide what information belongs to whom is IP and MAC address, which is probably not a very robust method.

To compensate, you'll have to A) Add more data to each sample, identifying the client, and B) Do more userspace processing, to identify the owner of each piece of data.

You need #2 because there is (probably) no point in sampling data every two seconds if the time relationship is random (is sample A 2 seconds before sample B, or vice versa?). To compensate, you'll have to A) Add more data to each sample, indicating the time ordering, and B) Do more userspace processing of each piece, to order the samples correctly.

Use TCP.

Community
  • 1
  • 1
CodeClown42
  • 11,194
  • 1
  • 32
  • 67
  • In the case of the OP, I don't think persistent connections are really needed. The consistency on the other hand seems to be more important to the OP, and so I would recommend TCP on that alone. – Some programmer dude Aug 30 '13 at 12:56
  • Point taken. I did assume that the specific origin of the data is important, which it might not be. I guess it is conceivable that the order isn't important either, in which case UDP starts to make sense. (Although: if the origin isn't important, it's hard to see how a consistent order would matter...) – CodeClown42 Aug 30 '13 at 13:04