Udpcast

udpcast@udpcast.linux.lu

553 discussions

Clarifying --fec argument
by Peter Story 01 Oct '23

01 Oct '23

Hello, I am running some benchmarks using UDPcast for a paper, and I wanted to confirm that I’ve understood the --fec argument. Here is what I’ve written: > The --fec argument specifies how many “stripes” each chunk of data is split into, the number of FEC packets included with each stripe, and the number of data packets in each stripe. For example, with --fec 8x16/128 each chunk of data will be sent in 8 stripes, and each stripe will have 16 FEC packets and 128 data packets. Hoping someone can confirm I’ve understood things correctly, or can correct me. Thanks! -Peter

2 1

Udpcast 20230924 released
by Alain Knaff 01 Oct '23

01 Oct '23

Hello all, Udpcast 20230924 is released. The most important changes are: - Also apply --ttl option if Rendez-vous address is unicast (because data address may still be multicast) - By default do not use SSM multicast address - Add support for SSM multicast (if address explicitly picked by user as data multicast address is an SSM address) - Do not mention --fec in usage message if FEC not compiled in - Use newest busybox and kernel - Fix unicode in Udpcast dialog system - Use newest Busybox (1.36.1) and Linux kernel (6.1.55) Regards, Alain

1 0

ttl multicast problem
by julien soula 01 Oct '23

01 Oct '23

hello, we found a problem in using updcast in a context of multi-routers when the rdv-addr is not multicast. Indeed, in this case, the multicast ttl must be greater than 1 (--ttl). But it is only assign during the processing of rdv-addr and only if rdv-addr is a multicast IP : udps-negotiate.c: /* Only do the following if controlMcastAddr is indeed an mcast address ... */ if(isMcastAddress(&net_config->controlMcastAddr)) { setMcastDestination(sock[0], net_config->net_if, &net_config->controlMcastAddr); setTtl(sock[0], net_config->ttl); But it is not assign during the processing of data-addr : udps-negotiate.c: if(isMcastAddress(&net_config->dataMcastAddr)) setMcastDestination(sock, net_config->net_if, &net_config->dataMcastAddr); Therefore, if rdv-addr is unicast then TTL remains to 1. So I suggest to patch the code this way : - if(isMcastAddress(&net_config->dataMcastAddr)) + if(isMcastAddress(&net_config->dataMcastAddr)) { setMcastDestination(sock, net_config->net_if, &net_config->dataMcastAddr); + setTtl(sock, net_config->ttl); + } Best regards, -- Julien Soula, Ingenieur Reseau, DSI/ULR2694, Universite de Lille, tel (0)3 20 62 34 55

2 1

Regression in Udpcast 20211207
by Robert Theron Brockman II 19 Mar '23

19 Mar '23

Howdy! I found a strange bug in the new version of Udpcast. When sending packets at speeds over around 80m, the program locks up. I traced the problem to the doRateLimit function in rate-limit.c (I've added some printfs): sleepTime = rateLimit->queueSize * 8 * MILLION / rateLimit->bitrate; printf("sleepTime1 %lu\n",sleepTime); printf("rateLimit->queueSize %lu\n",rateLimit->queueSize); if(sleepTime > 40000 || rateLimit->queueSize >= 100000) { printf("sleepTime2 %lu\n",sleepTime); sleepTime -= 10000; printf("sleepTime3 %lu\n",sleepTime); printf("sleepTime3 % 10000 %u\n",sleepTime % 10000); sleepTime -= sleepTime % 10000; printf("sleepTime4 %lu\n",sleepTime); usleep((useconds_t)sleepTime); } What is happening is that sometimes rateLimit->queueSize >= 100000 but sleepTime is small, so subtracting 10000 from it wraps around to near maxint. The strange thing is that when the program then does sleepTime -= sleepTime % 10000 the result is *different* from the 20200328 version because of the change to long unsigned integers. In the old version sleepTime would become zero, but now it stays huge, leading to an extremely long usleep. Here is the old behavior: sleepTime1 1338 rateLimit->queueSize 100350 sleepTime2 1338 sleepTime3 4294958634 sleepTime3 % 10000 4294958634 sleepTime4 0 Here is the new behavior (which hangs): sleepTime1 1344 rateLimit->queueSize 100800 sleepTime2 1344 sleepTime3 18446744073709542960 sleepTime3 % 10000 2960 sleepTime4 18446744073709540000 It looks to me like the older version actually had offsetting bugs: sleepTime % 10000 *should* return a value less than 10000 but in the old code for some reason it just returned sleepTime, which then subtracted from itself gave zero. In the new version the wraparound error from the sleepTime -= 10000 has been exposed, causing the hang. Anyway, hopefully this isn't too hard to fix: your program is super-useful for us, and the old version merrily blasts udp packets at gigabit speeds! Thanks, Robert II

2 1

musl build failure
by Fabrice Fontaine 13 Aug '22

13 Aug '22

Dear all, Please find attached a patch to fix a musl build failure. Best Regards, Fabrice

1 0

Udpcast 20211207 released
by Alain Knaff 11 Dec '21

11 Dec '21

Hello all, Udpcast 20211207 is released. The most important changes are: - --max-bitrate now works with bitrates greater than 2**31 - Use newest busybox (1.33.2) and kernel (5.10.83) - Lots of compiler warnings and variable type issues have been resolved Regards, Alain

1 0

Using UDPcast in a C program directly as a function
by cyber work 18 Jul '21

18 Jul '21

Dear sir, I would like to start by thanking you for your work on udpcast as it has been very useful for a lot of people and companies. I am reaching out in order to get some insight on how to use udpcast (sender & receiver) directly in C code without executing it from a bash call. To be clear, I would like to know if there is some kind of documentation on how to use these programs in C as functions that I could call. So far, every program that I have seen uses udp-sender and udp-receiver by a bash call inside a C or python code. This does not suit me because it slows significantly the speed of the program. Thanks a lot

1 0

option --nokbd doesn't send data
by Luke Robison 14 Jul '21

14 Jul '21

I am trying to push data through a one-way pipe in an automated way using udp-sender and udp-receiver. I have a working example, but can't get the --nokbd option to work on the sending side. Working Sender: yes | ~/udp-sender --async --fec 8x6/64 --max-bitrate 500M -f tmp_send_tarball.tar Receiver Command: ~/udp-receiver --pipe ~/rx_hook.sh --nokbd But notice I have to pipe the "yes" command into udp-sender to trigger the start from udp-sender. When instead I use --nokbd on the receiver, it hangs waiting for something after the control message. True to the documentation, it doesn't ask nor accept input, but it seems to fall into a default of "don't send" rather than a default of "send immediately" as I would expect. $ ~/udp-sender --async --fec 8x6/64 --max-bitrate 500M -f .tmp_send_tarball.tar --nokbd stripes=8 redund=6 stripesize=64 Udp-sender 20200328 Using mcast address 234.14.136.217 UDP sender for .tmp_send_tarball.tar at 10.14.136.217 on eno3 Broadcasting control to 10.14.143.255 <hangs here...> Am I missing something? Respectfully, Luke

1 0

Two or more clients drops bandwith by 2 orders of magnitude
by Brent Kimberley 07 Jul '21

07 Jul '21

William Please ensure you are using UDP/IGMP. Brent Hi, (I hope this list is still active) I am a newbie. I am testing multicast support on three computers connected through a gigabit switch. When only the server, ran as (rand.bin is a 1Gb file) udp-sender --interface eth1 --file rand.bin and ONE client udp-receiver --file rand.bin are connected, the bandwidth is around 937.32 Mbps, which is very good. But with two or more clients if consistently drops to 11 Mbps I would expect to bandwidth to decrease as 1/N, where N is the number of clients. What am I missing? I am using a dumb switch. Thanks -- Best regards / Cordialmente, William-Fernando Oquendo -------------------------- Este correo puede carecer de tildes o e?es debido al teclado. THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

2 2

Two or more clients drops bandwith by 2 orders of magnitude
by William Oquendo 03 Jul '21

03 Jul '21

Hi, (I hope this list is still active) I am a newbie. I am testing multicast support on three computers connected through a gigabit switch. When only the server, ran as (rand.bin is a 1Gb file) udp-sender --interface eth1 --file rand.bin and ONE client udp-receiver --file rand.bin are connected, the bandwidth is around 937.32 Mbps, which is very good. But with two or more clients if consistently drops to 11 Mbps I would expect to bandwidth to decrease as 1/N, where N is the number of clients. What am I missing? I am using a dumb switch. Thanks -- Best regards / Cordialmente, William-Fernando Oquendo -------------------------- Este correo puede carecer de tildes o eñes debido al teclado.

1 0

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast