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
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
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
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
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
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.
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.
Hi ALL
I am a IT teacher in Taiwan. I use Udpcast Windows version + WinPE to maintain our PC & NB for a lon time.
Udpcast is a very useful tool and helpful, thanks for all your works.
We now encounter an upgrade to 86-x64.
Can anyone help to compile Udpcast Windows 86-x64 version?
Sincerely
MS. Yang.
嘉義縣教育網路中心
05-2304464
Hello all,
Udpcast 20200328 is released.
The most important changes are:
- Use newest busybox (1.31.1) and kernel (5.0.21)
- Udp-sender now returns a non-zero exit status if a timeout expires at
start
- Fix compiler warnings and various typoes
- Fixes for Mingw
- Fix issues in assembly in fec.c
Unfortunately, due to bigger sizes produced by today's kernels, and due
to lack of usage, I dropped floppy support. Similarly, Etherboot support
has been dropped. Indeed PXE is the recommended net boot solution today.
Regards,
Alain