From mbillerwell at gmail.com Sun Feb 7 04:14:19 2010 From: mbillerwell at gmail.com (Markus) Date: Sun, 7 Feb 2010 14:14:19 +1100 Subject: [Udpcast] Optimum setting for zero packet loss Message-ID: <001101caa7a3$a5f0f3e0$f1d2dba0$@com> Hi Everyone, I have a requirement to send large tar packets in half duplex (one way only communication). I'm trying to determine what is the best values and to use in udp-sender and udp-receiver. My setup is, one server connected to another across a single 1Gb fibre link (no return path). The tar packets are sometimes very large, in the Gb's and I can't have any loss. My first setting were:- On the sending server:- udp-sender --async --log /tmp/log --fec 8x6/64 --max-bitrate 100m --autostart 1 --mcast-data-addr 224.2.2.2 --interface eth0 -f /root/send`date +%y%m%d%H%M`.tar There is a crontab to run this udp-sender line every 10 minutes to keep sending new packets. On the receiving server:- udp-receiver --interface eth0 --file /root/send`date +%y%m%d%H%M`.tar There is a crontab to run a script checking if udp-receiver is running and if not restarts it so it's ready for the next packet. I initially started the -max-bitrate at 1000m and it actually successfully got a tar packet across but after repetitive testing found it was dropping packets halfway through the transfer. So I continued to decrease the -max-bitrate. It got progressively better until I got to a bitrate of 100m. Then I found that the receiving server would start to receive the packet then dropped it straight away leaving a 0 byte size packet or occasionally a very small file (e.g 8Mb), which from observation I found it was dropping it almost instantly. I currently have a test running over the weekend with a couple of changed settings in the udp-sender:- udp-sender --async --log /tmp/log --fec 8x8/128 --max-bitrate 100m --autostart 3 --mcast-data-addr 224.2.2.2 --interface eth0 -f /root/send`date +%y%m%d%H%M`.tar I increased the fec in hope that it would improve the transfer speed and increased the autostart hoping it would help in not dropping out at the beginning of a reception. Could you please let me know your thoughts? Also if there are any things you think I should add or change in the udp-sender or udp-receiver to improve the reliability and transfer speed. For my requirements I really need to have a fasted transfer rate (and thought I'd get better than 100Mb on a 1Gb link) and I certainly can't go any slowed. I also require a zero loss performance. Thanks, Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From smark2ki at htl.moedling.at Mon Feb 8 18:40:49 2010 From: smark2ki at htl.moedling.at (=?iso-8859-1?Q?Markovic=B4=20Srdjan?=) Date: Mon, 8 Feb 2010 18:40:49 +0100 Subject: [Udpcast] New project using udpcast Message-ID: <91A3C1AA8EEA464FB4531B5CF2999A7FC51E950349@u-quickstep.htl-md.schule> Hi Everyone, we are developing a new multicast network installation system for linux and maybe other OSs that is using udpcast for transmission. This is our school examination project, so please do not send us patches or suggestions. After the examination, it will be developed as a normal OSS-project. If you like, you can follow us on twitter (http://twitter.com/mulin_project) or join us on Sourceforge (http://sourceforge.net/projects/mulin). Thanks for your support. - - Markovic Srdjan, 5AHELI Netzwerksupport HTBLuVA Mödling Tel: +43 2236 408 281 (Mo: 8:00 - 15:00) -x- routed via XWall 3.43 - HTBLuVA Moedling, Austria -x- From alban.rodriguez at univ-lr.fr Tue Feb 9 15:49:29 2010 From: alban.rodriguez at univ-lr.fr (Rodriguez Alban) Date: Tue, 9 Feb 2010 15:49:29 +0100 Subject: [Udpcast] does sender need to bind a socket to the multicast addr and receiver (portbase) port ? Message-ID: Hi, We're experiencing a strange behaviour with multicast igmp using udpcast. - sender (quite old 20081213) is running on a Linux SLES 11 64 bit on a VMware ESX guest - receivers (same version) are running on WinPE 2.0 x86 computers. - sender and receivers are on the same vlan This use to work amazingly well until for some reasons (correcting a bug actually), there was a firmware update on a 10GB Dell switch where the blade server is running all the VMware VMs. Now it doesn't work anymore: - the CMD_HELLO part woks as espected, and receivers are given their ID and the multicast data adress to join in. - then when the receiver actually sends CMD_GO, receivers don't even see the transfer has yet begun and sender finally quit after the normal timeout with no answer from participants. It seems clients never receive data sent to the multicast data address. So we made some tests using iperf as a multicast packet generator and rtpqual as a receiver; we could see that rtpqual was able to receive the packets only if we were also running an rtpqual on the machine we were generating the packet with iperf ! Then we made the same test with udp-sender and udp-receiver (2 receivers) and guess what ? it started to work as soon as we started an rtpqual process on the sender side ! we could observe that when rtpqual is not running on the sender machine igmp cuts the tree on the Dell switch and receivers aren't getting the stream anymore. It seems udp-sender should also bind to the multicast data address and portbase. Seen on udpcast source code (socklib.c): /** * Set socket to listen on given multicast address Not 100% clean, it * would be preferable to make a new socket, and not only subscribe it * to the multicast address but also _bind_ to it. Indeed, subscribing * alone is not enough, as we may get traffic destined to multicast * address subscribed to by other apps on the machine. However, for * the moment, we skip this concern, as udpcast's main usage is * software installation, and in that case it runs on an otherwise * quiet system. */ static int mcastListen(int sock, net_if_t *net_if, struct sockaddr_in *addr) { return mcastOp(sock, net_if, getSinAddr(addr), IP_ADD_MEMBERSHIP, "Subscribe to multicast group"); } However mcastListen is called from makeSocket() (socklib.c) which actually binds the socket. Latest version of udpcast (20100130) doesn't seem to bring any change and behaves the same. So, I tried to create an additional socket in startSender() (udps_negociate.c) and bind to RECEIVER_PORT(portBase): mysock = makeSocket(ADDR_TYPE_MCAST, net_config->net_if, net_config->dataMcastAddr, RECEIVER_PORT(net_config->portBase)); But I got the same behaviour :( So I pasted the whole openMC() function from rtpqual.c to socklib.c: #define NOERROR(val,msg) {if (((int)(val)) < 0) {perror(msg);exit(1);}} int openMC(name, port) char *name; int port; { struct sockaddr_in sin; struct ip_mreq mreq; struct hostent *hp; int fd, one=1; bzero(&sin, sizeof(struct sockaddr_in)); if (isdigit(*name)) { sin.sin_addr.s_addr = inet_addr(name); } else if (hp = gethostbyname(name)) { bcopy(hp->h_addr, (char *)&sin.sin_addr, hp->h_length); } else { printf("I Don't understand session name %s\n",name); exit(1); } sin.sin_family = AF_INET; sin.sin_port = port; if (!IN_MULTICAST(ntohl(sin.sin_addr.s_addr))) { printf("%s is not a multicast session\n", name); exit(1); } mreq.imr_multiaddr = sin.sin_addr; mreq.imr_interface.s_addr = INADDR_ANY; NOERROR(fd = socket(AF_INET, SOCK_DGRAM, 0), "socket"); NOERROR(setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)), "SO_REUSEADDR"); if (bind(fd, (const struct sockaddr *) &sin, sizeof(sin)) == -1) { perror("Using INADDR_ANY because"); sin.sin_addr.s_addr = INADDR_ANY; NOERROR(bind(fd, (const struct sockaddr *) &sin, sizeof(sin)), "bind"); } NOERROR(setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)), "IP_ADD_MEMBERSHIP"); return(fd); } And called it from the main() function from udp-sender.c myMcastDataAddr is a string copy from the command line argument because net_config structure only stores the sock_addr_in values and so that I can directly use the openMC() function without any modification. /* -- */ printf("addr = %s\n", myMcastDataAddr); printf("port = %d\n", RECEIVER_PORT(net_config.portBase)); printf("openMC()\n"); mysock = openMC(myMcastDataAddr, RECEIVER_PORT(net_config.portBase)); /* -- */ Indeed, it works now, despite this is a really ugly hack! However openMC() seems to do the same as makeSocket do: create the socket, bind to the specified multicast address and port and call a setsockopt for IP_ADD_MEMBERSHIP. So now it works for me, but it would be great if the correct patch (not mine) was integrated to the source code (maybe others would need it). EDIT: it works with makeSocket only if I call htons() to the port number: mysock = makeSocket(ADDR_TYPE_MCAST, net_config->net_if, &net_config->dataMcastAddr, htons(RECEIVER_PORT(net_config->portBase))); Other calls to makeSocket() doesn't use htons to swap the bytes so I initially I wasn't doing either ... thanks Alban -- Alban Rodriguez Centre de Ressources Informatiques Université de La Rochelle http://cri.univ-lr.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From breuer.jens at googlemail.com Tue Feb 9 16:19:44 2010 From: breuer.jens at googlemail.com (Jens Breuer) Date: Tue, 9 Feb 2010 16:19:44 +0100 Subject: [Udpcast] does sender need to bind a socket to the multicast addr and receiver (portbase) port ? In-Reply-To: References: Message-ID: <76ce20421002090719j1b354fay54a779bdccf9f0cf@mail.gmail.com> Hello Rodriguez You really should try with the most recent version of udpcast to check whether this problem has already been solved over the past 2 years. Additionally, I would recommend to triple-check the switch' configuration. From my experience in 99 out of 100 cases there is a network misconfiguration when experiencing problems with udpcast. Just my 0,5€. Kind regards Jens On Tue, Feb 9, 2010 at 3:49 PM, Rodriguez Alban wrote: > Hi, > We're experiencing a strange behaviour with multicast igmp using udpcast. > - sender (quite old 20081213) is running on a Linux SLES 11 64 bit on a > VMware ESX guest > - receivers (same version) are running on WinPE 2.0 x86 computers. > - sender and receivers are on the same vlan > This use to work amazingly well until for some reasons (correcting a bug > actually), there was a firmware update on a 10GB Dell switch where the blade > server is running all the VMware VMs. > Now it doesn't work anymore: > - the CMD_HELLO  part woks as espected, and receivers are given their ID and > the multicast data adress to join in. > - then when the receiver actually sends CMD_GO, receivers don't even see the > transfer has yet begun and sender finally quit after the normal timeout with > no answer from participants. > It seems clients never receive data sent to the multicast data address. > So we made some tests using iperf as a multicast packet generator and > rtpqual as a receiver; we could see that rtpqual was able to receive the > packets only if we were also running an rtpqual on the machine we were > generating the packet with iperf ! > Then we made the same test with udp-sender and udp-receiver (2 receivers) > and guess what ? it started to work as soon as we started an rtpqual process > on the sender side ! > we could observe that when rtpqual is not running on the sender machine igmp > cuts the tree on the Dell switch and receivers aren't getting the stream > anymore. > It seems udp-sender should also bind to the multicast data address and > portbase. > Seen on udpcast source code (socklib.c): > /** >  * Set socket to listen on given multicast address Not 100% clean, it >  * would be preferable to make a new socket, and not only subscribe it >  * to the multicast address but also _bind_ to it. Indeed, subscribing >  * alone is not enough, as we may get traffic destined to multicast >  * address subscribed to by other apps on the machine. However, for >  * the moment, we skip this concern, as udpcast's main usage is >  * software installation, and in that case it runs on an otherwise >  * quiet system. >  */ > static int mcastListen(int sock, net_if_t *net_if, struct sockaddr_in *addr) > { >     return mcastOp(sock, net_if, getSinAddr(addr), IP_ADD_MEMBERSHIP, >   "Subscribe to multicast group"); > } > However mcastListen is called from makeSocket() (socklib.c) which actually > binds the socket. > Latest version of udpcast (20100130) doesn't seem to bring any change and > behaves the same. > > So, I tried to create an additional socket in startSender() > (udps_negociate.c) and bind to RECEIVER_PORT(portBase): > mysock = makeSocket(ADDR_TYPE_MCAST, > net_config->net_if, > net_config->dataMcastAddr, > RECEIVER_PORT(net_config->portBase)); > > But I got the same behaviour :( > So I pasted the whole openMC() function from rtpqual.c to socklib.c: > #define NOERROR(val,msg) {if (((int)(val)) < 0) {perror(msg);exit(1);}} > int openMC(name, port) > char *name; > int port; > { >   struct sockaddr_in sin; >   struct ip_mreq mreq; >   struct hostent *hp; >   int fd, one=1; >   bzero(&sin, sizeof(struct sockaddr_in)); >   if (isdigit(*name)) { >     sin.sin_addr.s_addr = inet_addr(name); >   } >   else if (hp = gethostbyname(name)) { >     bcopy(hp->h_addr, (char *)&sin.sin_addr, hp->h_length); >   } >   else { >     printf("I Don't understand session name %s\n",name); >     exit(1); >   } >   sin.sin_family = AF_INET; >   sin.sin_port = port; >   if (!IN_MULTICAST(ntohl(sin.sin_addr.s_addr))) { >     printf("%s is not a multicast session\n", name); >     exit(1); >   } >   mreq.imr_multiaddr = sin.sin_addr; >   mreq.imr_interface.s_addr = INADDR_ANY; >   NOERROR(fd = socket(AF_INET, SOCK_DGRAM, 0), "socket"); >   NOERROR(setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)), >  "SO_REUSEADDR"); >   if (bind(fd, (const struct sockaddr *) &sin, sizeof(sin)) == -1) { >     perror("Using INADDR_ANY because"); >     sin.sin_addr.s_addr = INADDR_ANY; >     NOERROR(bind(fd, (const struct sockaddr *) &sin, sizeof(sin)), "bind"); >   } >   NOERROR(setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, > sizeof(mreq)), >  "IP_ADD_MEMBERSHIP"); >   return(fd); > } > And called it from the main() function from udp-sender.c > myMcastDataAddr is a string copy from the command line argument because > net_config structure only stores the sock_addr_in values and so that I can > directly use the openMC() function without any modification. > /* -- */ > printf("addr = %s\n", myMcastDataAddr); > printf("port = %d\n", RECEIVER_PORT(net_config.portBase)); > printf("openMC()\n"); > mysock = openMC(myMcastDataAddr, RECEIVER_PORT(net_config.portBase)); > /* -- */ > Indeed, it works now, despite this is a really ugly hack! > However openMC() seems to do the same as makeSocket do: create the socket, > bind to the specified multicast address and port and call a setsockopt for > IP_ADD_MEMBERSHIP. > So now it works for me, but it would be great if the correct patch (not > mine) was integrated to the source code (maybe others would need it). > EDIT: it works with makeSocket only if I call htons() to the port number: > mysock = makeSocket(ADDR_TYPE_MCAST, > net_config->net_if, > &net_config->dataMcastAddr, > htons(RECEIVER_PORT(net_config->portBase))); > Other calls to makeSocket() doesn't use htons to swap the bytes so I > initially I wasn't doing either ... > > > thanks > Alban > > -- > Alban Rodriguez > Centre de Ressources Informatiques > Université de La Rochelle > http://cri.univ-lr.fr > > > > > > _______________________________________________ > Udpcast mailing list > Udpcast at udpcast.linux.lu > https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast > > From alban.rodriguez at univ-lr.fr Tue Feb 9 18:16:16 2010 From: alban.rodriguez at univ-lr.fr (Alban Rodriguez) Date: Tue, 9 Feb 2010 18:16:16 +0100 Subject: [Udpcast] does sender need to bind a socket to the multicast addr and receiver (portbase) port ? In-Reply-To: References: Message-ID: Le 9 févr. 10 à 16:19, udpcast-request at udpcast.linux.lu a écrit : > > Date: Tue, 9 Feb 2010 16:19:44 +0100 > From: Jens Breuer > To: udpcast at udpcast.linux.lu > Subject: Re: [Udpcast] does sender need to bind a socket to the > multicast addr and receiver (portbase) port ? > Message-ID: > <76ce20421002090719j1b354fay54a779bdccf9f0cf at mail.gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Hello Rodriguez > > You really should try with the most recent version of udpcast to check > whether this problem has already been solved over the past 2 years. > > Additionally, I would recommend to triple-check the switch' > configuration. From my experience in 99 out of 100 cases there is a > network misconfiguration when experiencing problems with udpcast. > > Just my 0,5?. > > Kind regards > Jens Hi Jens, Thanks for your answer; as I wrote, latest version (20100130) does the same. This is why I had to look at the code and make this dirty hack. I'm pretty sure the Dell switch is culprit, but the multicast configuration looks good, and with the modified version of the sender multicast and igmp work as expected. Do you think it is acceptable for the sender to query the multicast data group itself as the general rule or could it bring some more problems ? ( the later case would require my patching of the code with each new release ...). Maybe Alain is the only one who can state here ... thanks Alban -- Alban Rodriguez Centre de Ressources Informatiques Université de La Rochelle http://cri.univ-lr.fr From kroe at rs-schesslitz.de Wed Feb 10 19:48:52 2010 From: kroe at rs-schesslitz.de (Dieter Kroemer) Date: Wed, 10 Feb 2010 19:48:52 +0100 Subject: [Udpcast] get snapin without fog-service Message-ID: <44FEBB9E-EE95-432C-8DAC-6F4049F4680F@rs-schesslitz.de> Hi, is there a possibility, that a client gets a snapin after reboot (e.g. with a batch-file in the autostart-folder), without using the fogservice? Kind regards Dieter From kroe at rs-schesslitz.de Wed Feb 10 19:55:42 2010 From: kroe at rs-schesslitz.de (Dieter Kroemer) Date: Wed, 10 Feb 2010 19:55:42 +0100 Subject: [Udpcast] fogservice takes to long Message-ID: <9B95E1D9-B274-4C68-979A-8613876E76C1@rs-schesslitz.de> Hi, I configured my fog-config-file, that the service inspects al 30 seconds, if there is a new snapin - sometime it works good, but sometimes it takes more than 6 minutes, untill the service recognizes, that there is an new snapin. Does anybody knows, why the service is sometimes so slow? Kind regards Dieter From breuer.jens at googlemail.com Wed Feb 10 20:03:48 2010 From: breuer.jens at googlemail.com (Jens Breuer) Date: Wed, 10 Feb 2010 20:03:48 +0100 Subject: [Udpcast] fogservice takes to long In-Reply-To: <9B95E1D9-B274-4C68-979A-8613876E76C1@rs-schesslitz.de> References: <9B95E1D9-B274-4C68-979A-8613876E76C1@rs-schesslitz.de> Message-ID: <76ce20421002101103i59f21252y1c3348d57ca0bf1b@mail.gmail.com> Hello Dieter, I don't know about FOG and I don't know whether there are FOG-users on the udpcast-mailing-list. However, you might have more luck trying these lists: http://sourceforge.net/mail/?group_id=201099 Kind regards Jens On Wed, Feb 10, 2010 at 7:55 PM, Dieter Kroemer wrote: > Hi, > > I configured my fog-config-file, that the service inspects al 30 seconds, if > there is a new snapin - sometime it works good, but sometimes it takes more > than 6 minutes, untill the service recognizes, that there is an new snapin. > > Does anybody knows, why the service is sometimes so slow? > > Kind regards > Dieter > _______________________________________________ > Udpcast mailing list > Udpcast at udpcast.linux.lu > https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast > From regis at manavi.com Wed Feb 10 21:36:36 2010 From: regis at manavi.com (Registrations) Date: Wed, 10 Feb 2010 12:36:36 -0800 Subject: [Udpcast] Keyboard Problem - DP55KG Message-ID: Hello Everyone, Sorry if this message is redundant. I am new to this list. UDPcast seems to not recognize my keyboard. In fact, I am having trouble with it recognizing my installed hard drive since it doesn't find any disk parameters I give it.. I have tried everything and I've come to the conclusion that maybe there is no support for my board at this point. I am using the Intel DP55KG motherboard. Does anyone know if this board is supported and if so, do you have a work around for this problem? Any help would be much appreciated. Payam -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain at knaff.lu Tue Feb 16 00:11:00 2010 From: alain at knaff.lu (Alain Knaff) Date: Tue, 16 Feb 2010 00:11:00 +0100 Subject: [Udpcast] does sender need to bind a socket to the multicast addr and receiver (portbase) port ? In-Reply-To: References: Message-ID: <4B79D484.8040008@knaff.lu> Rodriguez Alban wrote: > EDIT: it works with makeSocket only if I call htons() to the port > number: > > mysock = makeSocket(ADDR_TYPE_MCAST, > net_config->net_if, > &net_config->dataMcastAddr, > htons(RECEIVER_PORT(net_config->portBase))); > > Other calls to makeSocket() doesn't use htons to swap the bytes so I > initially I wasn't doing either ... makeSocket already does the byte-swapping itself (in the called function initSockAddress). So, by doing it here you really make it bind to a different port than the intended one. The effect would be the same as doing: mysock = makeSocket(ADDR_TYPE_MCAST, net_config->net_if, &net_config->dataMcastAddr, RECEIVER_PORT(net_config->portBase)+2); ... or even suppressing that call altogether... Could you try whether these 2 changes (or one of them) work with your hardware? Regards, Alain