0

I don't have much experience with network programming, but an interesting problem came up that requires it. The server will be transmitting multiple streams of different types of data to other machines. Each machine should be able choose which of the streams (one or more) it will like to receive. The whole setup is confined to the local network only. Initially, there will be only two clients, but I would like to design a scalable approach, if possible.

The existing server code, which is streaming only a single stream, is using TCP streaming socket for doing so. However, from some reading on the subject, I am not sure if this approach will scale to multiple streams and multiple clients well. The reason is: wouldn't two clients, who want to receive the same stream but connect via different TCP sockets, result in wastage of bandwidth? Especially compared to UDP, which allows to multicast.

Due to my inexperience, I am relying on better informed people out there to advise me: considering that i do want the stream to be reliable, would it be worth it to start from the scratch with UDP, and implement reliability into it, than to keep using TCP? Or, will this be better solved by designing an appropriate network structure? I'd be happy to provide more details if needed. Thanks.

UPDATE: I am looking at PGM and emcaster for reliable multicasting at the moment. Must have C# implementations at server side, and python implementations at client side.

oczkoisse
  • 1,561
  • 3
  • 17
  • 31
  • first off. Does it matter if the client doesnt get all the data from the stream or in the wrong order? – David Bern Jan 16 '17 at 21:30
  • Reliability is important, as each message in the stream is supposed to be sequential. The clients will be relying on the correct order to do useful processing on it. – oczkoisse Jan 16 '17 at 21:31
  • Well, I wouldnt bother using UDP. Why try to reimplement something someone already made to make sure of these 2 very important issues – David Bern Jan 16 '17 at 21:32
  • You are right. But is there a protocol that can multicast, but with reliability? – oczkoisse Jan 16 '17 at 21:33
  • http://stackoverflow.com/questions/21266008/can-i-use-broadcast-or-multicast-for-tcp – David Bern Jan 16 '17 at 21:34
  • 1
    Reliability requires bidirectional communication, but multicast (one to many) is unidirectional. Any missing information at one host would require resending it to all hosts. – Ron Maupin Jan 16 '17 at 22:26
  • UDP isn't a streaming protocol. Use TCP. – user207421 Jan 17 '17 at 00:18
  • What kind of data are you going to be sending (CSV files, text, etc.)? –  Jan 17 '17 at 14:19
  • Nothing textual actually. All streams are going to be binary data of different types. – oczkoisse Jan 17 '17 at 16:44

1 Answers1

1

Since you want a scalable program, then UDP would be a better choice, because it does not go the extra length to verify that the data has been received, thus making the process of sending data faster.

  • Based on the comment,"_Reliability is important, as each message in the stream is supposed to be sequential. The clients will be relying on the correct order to do useful processing on it,_" UDP would be unacceptable. – Ron Maupin Jan 19 '17 at 22:18
  • However, since UDP is faster than TCP, this allows for more streams, therefore being able to serve more clients, making this a more scalable approach. –  Jan 23 '17 at 19:17
  • 1
    I understand, but the OP wants reliability and packet ordering, and UDP doesn't provide that. It can be added to UDP by the application, but you have not addressed the problems with UDP regarding the request. – Ron Maupin Jan 23 '17 at 19:24
  • Late already, but for others who will see this question, SCTP where available, looks like what the OP needs, or could be more easily adapted to what the OP needs – gbenroscience Mar 28 '20 at 00:22