Hi guys, I'm using udp-sender to send an announce package and using udp-receiver inside of a C program in loop who stays checking for new announce packages. The announce package has no more then 1.5K The problem is, after some interactions, udp-receiver lock and stay quiet waiting for close the connection by sender, but the announce is complete inside the system. So, my question is, can I put a timeout in udp-receiver to close this connection if some defined time pass away?
Diego Zimmermann wrote:
Hi guys, I'm using udp-sender to send an announce package and using udp-receiver inside of a C program in loop who stays checking for new announce packages. The announce package has no more then 1.5K The problem is, after some interactions, udp-receiver lock and stay quiet waiting for close the connection by sender, but the announce is complete inside the system. So, my question is, can I put a timeout in udp-receiver to close this connection if some defined time pass away?
Sorry, but in my opinion, this would not be a valid solution. Rather, try to find out why it happens in the first place. Tcpdump may help with the analysis.
Which command line options do you use? Does the problem also happen on a LAN (with the same command-line parameters used). Does it only happen with small files?
Regards,
Alain
Thanks by your replay Alain. I use udp-sender/receiver in a LAN too but the problem doesn't exists. I'm using tcpdump to check what packages it's coming by satellite, but in there looks normal. I don't know if a solution with timeout can solve my problem, but its my first choose to fix this problem. Anyone have this problem related or know anyone who have this before?
Thanks a lot
On Fri, Feb 27, 2009 at 12:40 PM, Alain Knaff alain@knaff.lu wrote:
Diego Zimmermann wrote:
Hi guys, I'm using udp-sender to send an announce package and using udp-receiver inside of a C program in loop who stays checking for new announce
packages.
The announce package has no more then 1.5K The problem is, after some interactions, udp-receiver lock and stay quiet waiting for close the connection by sender, but the announce is complete inside the system. So, my question is, can I put a timeout in udp-receiver to close this connection if some defined time pass away?
Sorry, but in my opinion, this would not be a valid solution. Rather, try to find out why it happens in the first place. Tcpdump may help with the analysis.
Which command line options do you use? Does the problem also happen on a LAN (with the same command-line parameters used). Does it only happen with small files?
Regards,
Alain
Diego Zimmermann wrote:
Thanks by your replay Alain. I use udp-sender/receiver in a LAN too but the problem doesn't exists. I'm using tcpdump to check what packages it's coming by satellite, but in there looks normal. I don't know if a solution with timeout can solve my problem, but its my first choose to fix this problem. Anyone have this problem related or know anyone who have this before?
Thanks a lot
Maybe somebody might be able to help if you provided more details (such as the command-line parameters that you used)?
Regards,
Alain
On Fri, Feb 27, 2009 at 12:40 PM, Alain Knaff alain@knaff.lu wrote:
Diego Zimmermann wrote:
Hi guys, I'm using udp-sender to send an announce package and using udp-receiver inside of a C program in loop who stays checking for new announce
packages.
The announce package has no more then 1.5K The problem is, after some interactions, udp-receiver lock and stay quiet waiting for close the connection by sender, but the announce is complete inside the system. So, my question is, can I put a timeout in udp-receiver to close this connection if some defined time pass away?
Sorry, but in my opinion, this would not be a valid solution. Rather, try to find out why it happens in the first place. Tcpdump may help with the analysis.
Which command line options do you use? Does the problem also happen on a LAN (with the same command-line parameters used). Does it only happen with small files?
Regards,
Alain
Sorry, I forgott in the first mail I'm using udp-sender --async --mcast-data-address 229.1.1.1 --mcast-rdv-addr 229.1.1.1 --autostart 1 --fec 8x8/128 --max-bitrate 500k --interface eth1 --portbase 4002 -f announce and udp-receiver --nosync --mcast-rdv-addr 229.1.1.1 --interface dvb0_0 --portbase 4002 -f announce
On Fri, Feb 27, 2009 at 3:09 PM, Alain Knaff alain@knaff.lu wrote:
Diego Zimmermann wrote:
Thanks by your replay Alain. I use udp-sender/receiver in a LAN too but the problem doesn't exists. I'm using tcpdump to check what packages it's coming by satellite, but in there looks normal. I don't know if a solution with timeout can solve my problem, but its my first choose to fix this problem. Anyone have this problem related or know anyone who have this before?
Thanks a lot
Maybe somebody might be able to help if you provided more details (such as the command-line parameters that you used)?
Regards,
Alain
On Fri, Feb 27, 2009 at 12:40 PM, Alain Knaff alain@knaff.lu wrote:
Diego Zimmermann wrote:
Hi guys, I'm using udp-sender to send an announce package and using udp-receiver inside of a C program in loop who stays checking for new announce
packages.
The announce package has no more then 1.5K The problem is, after some interactions, udp-receiver lock and stay
quiet
waiting for close the connection by sender, but the announce is
complete
inside the system. So, my question is, can I put a timeout in udp-receiver to close this connection if some defined time pass away?
Sorry, but in my opinion, this would not be a valid solution. Rather,
try
to find out why it happens in the first place. Tcpdump may help with the analysis.
Which command line options do you use? Does the problem also happen on a LAN (with the same command-line parameters used). Does it only happen
with
small files?
Regards,
Alain
Diego Zimmermann wrote:
Sorry, I forgott in the first mail I'm using udp-sender --async --mcast-data-address 229.1.1.1 --mcast-rdv-addr 229.1.1.1 --autostart 1 --fec 8x8/128 --max-bitrate 500k --interface eth1 --portbase 4002 -f announce and udp-receiver --nosync --mcast-rdv-addr 229.1.1.1 --interface dvb0_0 --portbase 4002 -f announce
Indeed, on a LAN this seems to work (changing just the name of the interface)
And the parameters are set up ok for return-channel-less transmission (verified by setting iptables on sender to drop all return traffic: still works).
As communication is now purely unidirectional, satellite latency should not make a difference either.
So, this is really weird, could you check the settings on your routers, encapsulators, etc. to make sure they aren't dropping any packets along the way? A tcpdump taken at the client, and another one at the server (just ports 4002 and 4003) would also be helpful to see whether anything is lost.
However, while running a tcpdump myself, one thing struck me: you set fec to use 8 slices size with 8 redundant packets. This is fine for large files. But for just 1500 bytes (2 payload packets), this is way overkill: indeed, this means that at least 64 packets will be transmitted (8 redundant packets for each of the 8 slices). Of these 8 slices, 6 would be completely useless, as they'd contain _only_ redundant packets, and no data packets.
--fec 1x2/128 would be more appropriate. This would still give you 100% redundancy (2 redundant packets per 2 data packets) but be far less wasteful.
Regards,
Alain
-
Alain Knaff -
Diego Zimmermann