Udpcast October 2010

udpcast@udpcast.linux.lu

2 participants
8 discussions

by George Coulouris

Hello, If udp-receiver is writing to a pipe and the pipe fails, udp-receiver will incorrectly exit with a returncode of zero. This is easily tested with a trivial pipe program that copies stdin to stdout, but exits with a nonzero status upon encountering eof. Adding the following to startReceiver() in udpr-negotiate.c is sufficient to fix this behavior: <---- cut here int ret; ... if(pipePid) { ret=udpc_waitForProcess(pipePid, "Pipe"); } ... return ret; <---- cut here Regards, George Coulouris National Center for Biotechnology Information (contractor)

11 years, 1 month

patch submit: Use "flprintf()" on every printout on stderr

by Julien Aube

Hello, While using udpcast, I found out that it may be very verbose on stderr, even if a logfile is specified. This turns out to be a problem for our embedded application where the stderr is a (slow) serial port. So here is a patch which replace every occurrence of fprint(sdterr,...) by the flprintf() function defined in log.c. I thought it might be of some use for people. (This patch also happen to cleanup the blank spaces at end of lines) Julien -- People in the embedded space don't do prototypes. They hack something until it works, then it's done. --- Always code as if the person who will maintain your code is a maniac serial killer that knows where you live

11 years, 10 months

castomize udpcast iso image

by Gianluigi Autuori

I want to use Udpcast from iso image in this scenario: - first pc boots from udpcast iso image -second pc boots from ethernet using pxe that sends him udpreceiver How can I do it? thanks

11 years, 10 months

patch submit: Provide a watchdog on receiver

by Julien Aube

Hello, I've made the attached patch to prevent the situation where the udp-receiver hang out indefinitly waiting for data when the server has been killed after having started to send data. In this case, the udp-received program would hang indefinitly. Since in my program, udp-receiver is called through system(...); the result is a hang. With this patch I use a SIGALARM signal to reset a flag to 0, and act as a watchdog. The watchdog is started just before the sending data phase of the protocol, and is feed each time a packet is received from the server. If 2 times in a row the watchdog is not feed, the program exit in error. The current value is set as a #define as 60s, which is in effect 2mn before udp-receiver is actually killed. However I am aware that this implementation is somehow crude, and I would be interested by any other way to do that. Additionally, if someone is interested by this patch, I could make it so that the watchdog period is configurable on the command-line. Thanks for your time, Julien -- People in the embedded space don't do prototypes. They hack something until it works, then it's done. --- Always code as if the person who will maintain your code is a maniac serial killer that knows where you live

11 years, 10 months

Support for Apple iMac keyboards (hid_apple) in udpcast images

by Frederik Himpe

I tried booting a recent Apple iMac with the latest kernel and an initrd from cast-o-matic, but the kayboard fails to work. Looking at an installed Debian system, the module hid_apple is loaded. Is this driver missing from the udpcast images, and is it possible to add it? -- Frederik Himpe <fhimpe(a)vub.ac.be> Vrije Universiteit Brussel

11 years, 10 months

Socket problem in receiver

by Sergio Sánchez Vega

Hello, I´m using latest udpcast versión (20100130) in Debian machines to transfer files in unidirectional mode. Sometimes I see the next message in receiver machine: Receiver error After putting some fprintf I realized the problem is in the file udpr-negotiate.c in line 191: sock = udpc_selectSock(client_config.socks, NR_CLIENT_SOCKS, net_config->startTimeout); if(sock < 0) { return -1; } Why sock is < 0? What should I do? Thanks

11 years, 11 months

static compile

by cruejones＠comcast.net

Is there an easy way to statically compile udpcast? currently: # ldd udp-receiver linux-vdso.so.1 => (0x00007fffde082000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fd71bef7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd71bcda000) libc.so.6 => /lib64/libc.so.6 (0x00007fd71b97c000) /lib64/ld-linux-x86-64.so.2 (0x00007fd71c0fb000) thanks

11 years, 11 months

Fast .. and then slow....

by Matheson, Edward B. (LARC-D318)[LITES]

First: kickass tool .. love it! Second: weird problem. - I have ~320 blades connected to 32 bladeswitches .. and then trunked to a cisco 4503. - Each bladeswitch has 4 connections to the cisco .. port-channeled and trunked. - I found with much trouble.. that one MUST force duplex full, speed 1000 .. made a big difference - however, I have a weird problem where i start around 230Mbps .. and end about 50Mbps on transfer to about 64 blades. Not sure why. It stays nice and fast thru about the first 12gig .. but slows down from there until I hit the total of about 26 gig. I am using pigz ( nice way to make this faster ) thusly: append load_ramdisk=1 dhcp=yes port=9002 umode=snd auto=yes lang=US kbmap=US initrd=/udpcast/initrd root=01:00 compr=lzop netmodule=AUTO netmodparm= enableDiskmodule=yes diskmodule=ahci diskmodparm= disk=/dev/cciss!c0d0 udpcparam="--pipe /pigz -c --full-duplex" ( the disk is because these blades have weird controllers .. darn hp ) Anyone know why it would slow down over time? It's almost asymptotic. -b PS > I am working on a few patches .. - to incorporate pigz from the makeImage .. - to use partedImage to read/write to the image on the drive. ( All my machines are 1 partition ) E Branson Matheson ATOL Experiment Specialist edward.b.matheson(a)nasa.gov<mailto:edward.b.matheson@nasa.gov> x49054

12 years, 7 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast October 2010