2

I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.

From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.

But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.

My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?

I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?

The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself. Those messages are encrypted like below, and they might bet bigger sometimes.

e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8

NaN
  • 8,596
  • 20
  • 79
  • 153
  • Well should you? What are you sending? Are the messages absolutely necessary to get to your clients? If you are *streaming* data, like audio or video, then no, don't be worried. But if they are messages regarding state, or "important updates" to the client machines, then yes. You can mix the two as well. – Kirk Backus Aug 06 '13 at 00:29
  • @KirkBackus I've updated the question with that information. – NaN Aug 06 '13 at 00:38
  • 1
    Awesome! Yes, you should definitely use TCP. You don't have to, however. You can use UDP, but you would have to have a confirmation system to make sure the information got there (which is a problem TCP already solves) – Kirk Backus Aug 06 '13 at 00:46
  • 3
    You should do more research. [Tcp Reliability versus Udp Burdens](http://stackoverflow.com/q/2354091/62576) has an accepted answer that has many links that discuss the reliability of UDP, and the common answer to all of those links is "use UDP if you can handle lost packets of data". As you're wanting to use it for access information, privileges, and software updates, can you really have packets missing? (What happens when you update an executable with a corrupted replacement that won't run? What happens when a user can't get access because a packet was lost?) – Ken White Aug 06 '13 at 00:56

1 Answers1

3

I decided to use them both!

Simple use case:

In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.

If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.

Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.

What do you think of that approach?

NaN
  • 8,596
  • 20
  • 79
  • 153
  • 1
    It is not an uncommon use of UDP, so will usually work. But it is not the only option. There are other discovery protocols available for locating services on networks. And multicasting might work better for status broadcasts and such. – Remy Lebeau Aug 06 '13 at 02:38
  • 1
    [ActiveMQ](http://activemq.apache.org)-Server is sending an UDP-Broadcast with the address to all clients – Sir Rufo Aug 06 '13 at 05:19
  • It's me coming to a conclusion when I did not found any other way, I was going to loose something if I took only one of those two roads. – NaN Aug 06 '13 at 16:45