UDP Datagramreceivedfcn unresponsive on first datagram
in [Matlab]
|
From: Jonas on 11 Aug 2010 17:45 Hello, I'm using UDP to communicate between Matlab programs on separate computers. The two programs essentially operate in a master/slave configuration. For some reason, the first datagram sent from the master doesn't trigger the datagramreceivedfcn at the slave most, but not all the time. This causes the master to hang, since it is waiting for a response from the slave. I can interrupt at the master, which causes a second datagram to be sent to the slave. The slave typically sees the second datagram, and afterward works as expected. Any idea why this happens or how I might rectify the situation? I'm using fwrite to send information over the connection, and fread to read it. The datagramreceviedfcn is used only on the slave side. Thanks.
From: Trent Jarvi on 12 Aug 2010 12:13 "Jonas " <i_wear_pants(a)hotmail.com> wrote in message news:i3v5j5$f8m$1(a)fred.mathworks.com... > Hello, > > I'm using UDP to communicate between Matlab programs on separate > computers. The two programs essentially operate in a master/slave > configuration. For some reason, the first datagram sent from the master > doesn't trigger the datagramreceivedfcn at the slave most, but not all the > time. This causes the master to hang, since it is waiting for a response > from the slave. I can interrupt at the master, which causes a second > datagram to be sent to the slave. The slave typically sees the second > datagram, and afterward works as expected. > > Any idea why this happens or how I might rectify the situation? > > I'm using fwrite to send information over the connection, and fread to > read it. The datagramreceviedfcn is used only on the slave side. > > Thanks. > Hi Jonas, You may want to try watching the incoming data with a network monitoring tool like WireShark. A quick test here shows the callback is working 100/100 attempts when testing via localhost. Note that you should plan on packets being lost. UDP can drop packets when the network/operating system are over burdened so your code will need to be able to handle that fault mode. >> echoudp('on',7000) >> u=udp('localhost',7000) UDP Object : UDP-localhost Communication Settings RemotePort: 7000 RemoteHost: localhost Terminator: 'LF' Communication State Status: closed RecordStatus: off Read/Write State TransferStatus: idle BytesAvailable: 0 ValuesReceived: 0 ValuesSent: 0 >> u.DatagramTerminateMode ans = on >> u.ReadAsyncMode ans = continuous >> u.DatagramReceivedFcn=(a)instrcallback UDP Object : UDP-localhost Communication Settings RemotePort: 7000 RemoteHost: localhost Terminator: 'LF' Communication State Status: closed RecordStatus: off Read/Write State TransferStatus: idle BytesAvailable: 0 ValuesReceived: 0 ValuesSent: 0 >> fopen(u) >> fwrite(u,'asdf') DatagramReceived event occurred at 11:24:42 for the object: UDP-localhost. 4 bytes were received from address 127.0.0.1, port 7000. >> u UDP Object : UDP-localhost Communication Settings RemotePort: 7000 RemoteHost: localhost Terminator: 'LF' Communication State Status: open RecordStatus: off Read/Write State TransferStatus: idle BytesAvailable: 4 ValuesReceived: 0 ValuesSent: 4
|
Pages: 1 Prev: UDP Datagramreceivedfcn unresponsive on first datagram Next: turn off MATLAB prompts |