Yes I understand that but: >each byte you receive may be in a different datagram... UDP is not serialized and guaranteed to arrive in order... UDP datagrams may not even make it >from the startpoint to the endpoint...
In my case one datagram is only one byte of payload (plus UDP header and IP header). TCP is good if you make transfer of large blocks of data, to make sure that everything is completely received in the right order. But in my case it is a kind of a signalling protocol of only one byte payload every 100ms, that tells the remote side weather the local side (of a custom made IP telephone system) is ON-HOOK or OFF-HOOK (telephone handset put on the cradle or not). That means that a condition that was detected by the local side 100ms ago is completely irrelevant after that time. So loss of datagrams is completely acceptable as it is only the present situation that is important. And above all, the signalling has to be lightweight in terms of bitrate as we only have one E1 (2048kbit/s) for the transmission of encoded voice (32k) and signalling and in this E1 other services are transmitted as well! That is why UDP is the right choice. My personal problem was only the confusion regarding source and destination port numbers. Yours friendly CS -----Ursprüngliche Nachricht----- Von: wkitt...@windstream.net [mailto:wkitt...@windstream.net] Gesendet: Montag, 19. Dezember 2016 17:10 An: synalist-public@lists.sourceforge.net Betreff: Re: [Synalist] filtering of UDP port numbers On 12/19/2016 09:31 AM, S.C.T.N Gmbh wrote: > ok, thank you. > > But does it really make sense in my case, as I know that I have to > expect one byte of payload every 100ms? each byte you receive may be in a different datagram... UDP is not serialized and guaranteed to arrive in order... UDP datagrams may not even make it from the startpoint to the endpoint... > And moreover I am testing IP connectivity with this loop, that is, a > timer is reset at any time the datagram is received and whenever the > actual timespan between last receive and actual time is >100ms the SW > detects that IP connectivity to the remote host is down. but it may not be "down"... the datagram may simply not have made it all the way through the pipe... that doesn't mean the connection, as such, is down... only that the datagram didn't make it OR that it may arrive later... if you really want a more serial like connection, TCP is much better because you are guaranteed that data will arrive in the proper order, built-in error detection/correction, two way comms over the link, you know when the connection is terminated from either end... there are other reasons, too, but these are the first i can think of related to what little i know of your project... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. ---------------------------------------------------------------------------- -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ synalist-public mailing list synalist-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synalist-public ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ synalist-public mailing list synalist-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synalist-public
