Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This is by design.</p> <p>UDP communication is connection less as compared to TCP which need a connection.</p> <p>When sending data from UDP it is broadcasted. Which means it will be available only to receiver which are alive at a time of broadcasting.</p> <p>Example :</p> <p>TCP is like a phone call. Caller calls receiver. Receiver accepts call and the communication happens. If receiver is not available caller will get a error.(Caller is client and receiver is server listening on a port)</p> <p>UDP is like FM radio broadcasting. A song is broadcasted on radio irrespective of if anyone is listening on other end or not. If the receivers had put their radio set on they will receive the song. If song is transmitted at 10:30 and my radio set is on at 10:30 , I can hear the song. But if I put my raido set on at 10:35 then it means I have missed it and would not be able to hear it again.</p> <p><strong>Update</strong></p> <p>As I can see the real problem is transmitting on port 1111(for example) though application X and receiving on port 1111 through application Y on SAME Machine is what you are trying to achieve.</p> <p>For the same I can suggest 2 workarounds(not good but workable).</p> <ol> <li><p>As you said if you start the transmitter after starting the receiver all is fine. So just try and put the logic of RESTARTING the transmitter periodically.</p></li> <li><p>Transmit and receive on 2 ports every time. eg. 1111 and 2222. The remote hardware will use the first set of 1111 and the demoing application will use 2222.</p></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload