From alain at knaff.lu  Tue Sep  1 00:07:26 2009
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 01 Sep 2009 00:07:26 +0200
Subject: [Udpcast] using async and pointopoint options together
In-Reply-To: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>
References: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>
Message-ID: <4A9C499E.1060805@knaff.lu>

Selçuk Cevher wrote:
> Hi All,
> 
> Does udpcast currently allow using async and pointopoint options together ?
> 
> That is, I want to specify the unicast address of the participant manually
> from the command line.
> 
> I noticed that the same question was raised in last January, 2009, and the
> answer was "not -yet- supported":
> 
> http://udpcast.linux.lu/pipermail/udpcast/2009-January/000956.html
> 
> Thanks.
> 

Actually, it is supported, albeit roundabout way: you simply specify the
pointopoint address as a data address (-m option), and drop the
-pointopoint option:

udp-sender --fec 8x8 --async src2  -m 192.168.1.5 --max-bitrate 8m

This will send to the unicast address 192.168.1.5 in async mode.

Regards,

Alain


From cevhers at gmail.com  Tue Sep  1 07:51:24 2009
From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=)
Date: Tue, 1 Sep 2009 08:51:24 +0300
Subject: [Udpcast] using async and pointopoint options together
In-Reply-To: <4A9C499E.1060805@knaff.lu>
References: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>
	<4A9C499E.1060805@knaff.lu>
Message-ID: <803a75c30908312251m39dd8bfg60c49466b9f641ee@mail.gmail.com>

But it still requires at least one connection from the udp-receiver clients,
doesn't it ?

Can I force udp-sender not to wait for at least one connection from the
clients without modifying the source code ? or Do I have to modify it ?

On Tue, Sep 1, 2009 at 1:07 AM, Alain Knaff <alain at knaff.lu> wrote:

> Selçuk Cevher wrote:
> > Hi All,
> >
> > Does udpcast currently allow using async and pointopoint options together
> ?
> >
> > That is, I want to specify the unicast address of the participant
> manually
> > from the command line.
> >
> > I noticed that the same question was raised in last January, 2009, and
> the
> > answer was "not -yet- supported":
> >
> > http://udpcast.linux.lu/pipermail/udpcast/2009-January/000956.html
> >
> > Thanks.
> >
>
> Actually, it is supported, albeit roundabout way: you simply specify the
> pointopoint address as a data address (-m option), and drop the
> -pointopoint option:
>
> udp-sender --fec 8x8 --async src2  -m 192.168.1.5 --max-bitrate 8m
>
> This will send to the unicast address 192.168.1.5 in async mode.
>
> Regards,
>
> Alain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.udpcast.linux.lu/pipermail/udpcast/attachments/20090901/9b360800/attachment.html>

From alain at knaff.lu  Tue Sep  1 09:23:58 2009
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 01 Sep 2009 09:23:58 +0200
Subject: [Udpcast] using async and pointopoint options together
In-Reply-To: <803a75c30908312251m39dd8bfg60c49466b9f641ee@mail.gmail.com>
References: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>	
	<4A9C499E.1060805@knaff.lu>
	<803a75c30908312251m39dd8bfg60c49466b9f641ee@mail.gmail.com>
Message-ID: <4A9CCC0E.3000005@knaff.lu>

On 09/01/09 07:51, Selçuk Cevher wrote:
> But it still requires at least one connection from the udp-receiver clients,
> doesn't it ?
> 
> Can I force udp-sender not to wait for at least one connection from the
> clients without modifying the source code ? or Do I have to modify it ?
> 
> On Tue, Sep 1, 2009 at 1:07 AM, Alain Knaff <alain at knaff.lu> wrote:

Async mode in unidirectional, there are no connections from clients needed.

Regards,

Alain


From cevhers at gmail.com  Tue Sep  1 16:00:02 2009
From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=)
Date: Tue, 1 Sep 2009 17:00:02 +0300
Subject: [Udpcast] using async and pointopoint options together
In-Reply-To: <4A9CCC0E.3000005@knaff.lu>
References: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>
	<4A9C499E.1060805@knaff.lu>
	<803a75c30908312251m39dd8bfg60c49466b9f641ee@mail.gmail.com>
	<4A9CCC0E.3000005@knaff.lu>
Message-ID: <803a75c30909010700g5aedf1bk63ff3b7107ef6c7d@mail.gmail.com>

I have one more question.

Does udp-receiver provide an option to specify a specific IP address to
listen on ?

I am asking this because I want to try udp-receiver with some application
other than udp-sender on the sending side.

On Tue, Sep 1, 2009 at 10:23 AM, Alain Knaff <alain at knaff.lu> wrote:

> On 09/01/09 07:51, Selçuk Cevher wrote:
> > But it still requires at least one connection from the udp-receiver
> clients,
> > doesn't it ?
> >
> > Can I force udp-sender not to wait for at least one connection from the
> > clients without modifying the source code ? or Do I have to modify it ?
> >
> > On Tue, Sep 1, 2009 at 1:07 AM, Alain Knaff <alain at knaff.lu> wrote:
>
> Async mode in unidirectional, there are no connections from clients needed.
>
> Regards,
>
> Alain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.udpcast.linux.lu/pipermail/udpcast/attachments/20090901/8b7c09c4/attachment.html>

From alain at knaff.lu  Tue Sep  1 23:37:43 2009
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 01 Sep 2009 23:37:43 +0200
Subject: [Udpcast] using async and pointopoint options together
In-Reply-To: <803a75c30909010700g5aedf1bk63ff3b7107ef6c7d@mail.gmail.com>
References: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>	<4A9C499E.1060805@knaff.lu>	<803a75c30908312251m39dd8bfg60c49466b9f641ee@mail.gmail.com>	<4A9CCC0E.3000005@knaff.lu>
	<803a75c30909010700g5aedf1bk63ff3b7107ef6c7d@mail.gmail.com>
Message-ID: <4A9D9427.5000802@knaff.lu>

Selçuk Cevher wrote:
> I have one more question.
> 
> Does udp-receiver provide an option to specify a specific IP address to
> listen on ?

You can specify an address to use to listen for the HELLO packet
(--mcast-rdv-address option), which itself will then contain a suggested
address for the multicast transfer.

If your machine has more than one ethernet card, you may also pick which
card to use using the -i option. This influences the unicast adress that
the receiver uses.

Regards,

Alain

> I am asking this because I want to try udp-receiver with some application
> other than udp-sender on the sending side.
> 
> On Tue, Sep 1, 2009 at 10:23 AM, Alain Knaff <alain at knaff.lu> wrote:
> 
>> On 09/01/09 07:51, Selçuk Cevher wrote:
>>> But it still requires at least one connection from the udp-receiver
>> clients,
>>> doesn't it ?
>>>
>>> Can I force udp-sender not to wait for at least one connection from the
>>> clients without modifying the source code ? or Do I have to modify it ?
>>>
>>> On Tue, Sep 1, 2009 at 1:07 AM, Alain Knaff <alain at knaff.lu> wrote:
>> Async mode in unidirectional, there are no connections from clients needed.
>>
>> Regards,
>>
>> Alain
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast



From alain at knaff.lu  Tue Sep  1 23:40:33 2009
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 01 Sep 2009 23:40:33 +0200
Subject: [Udpcast] how to by-pass HELLO message mechanism through -m
 option ?
In-Reply-To: <803a75c30908310539t7ff65a4ev6780a6d91e5b0ff8@mail.gmail.com>
References: <803a75c30908310539t7ff65a4ev6780a6d91e5b0ff8@mail.gmail.com>
Message-ID: <4A9D94D1.8010507@knaff.lu>

The hello packets contains other parameters than just the multicast
address (such as blocksize and capabilities). So, the -m option is not
enough to convey all information that is in the HELLO packet

Regards,

Alain

Selçuk Cevher wrote:
> Hi All,
> 
> I want to use udpcast in unicast (or pointopoint) mode.
> 
> However, I do not want udp-sender to determine whether to use unicast or
> multicast based on the number of connections coming from the clients since I
> want to test udp-sender along with another application on the receiving side
> other than udp-receiver (In this framework, there won't be any connections
> coming from the clients).
> 
> Based on above, I want udp-sender to use the unicast destination IP address
> provided by the user from the command line or it may be even hard-coded into
> the source code.
> 
> I tried to use -m option to specify a unicast address instead of a multicast
> address to "trick" udpcast.
> 
> But, it did not like that. I guess that it got some kind of negative
> feedback from the existing udp-receiver clients, and aborted the transfer
> since the clients were expecting a "proper" multicast address after -m
> option.
> 
> Any ideas to overcome this issue ?
> 
> Thanks.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast



From alain at knaff.lu  Tue Sep  1 23:43:24 2009
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 01 Sep 2009 23:43:24 +0200
Subject: [Udpcast] Udpcast for streaming data.
In-Reply-To: <4A6D9D6B.90205@knaff.lu>
References: <4A673FFC.2090609@enigma.det.uvigo.es> <4A6D9D6B.90205@knaff.lu>
Message-ID: <4A9D957C.4090509@knaff.lu>

Alain Knaff wrote:
> On 07/22/09 18:36, Jorge Muñoz Castañer wrote:
>> Hi list,
>>
>> I was looking for a tool to send a stream of data with FEC where the 
>> client/receiver can connect even if the stream has yet begun. I haven't 
>> found anything but Udpcast that can do anything similar. I think that 
>> maybe an "streaming" option can be added so the sender sends Hello 
>> packets at the end of a block of slices+FEC so a receiver can hook to 
>> the UDP stream.
>>
>> What do you think about this? Can this be made modifying Udpcast without 
>> broken it all? Is there another software that I can use?
>>
>> Greetings,
>>
>> Jorge M
>>
> 
> Sounds like a good idea. I'll consider adding this for the next version.
> 
> Regards,
> 
> Alain

I just released version 20090830, which has support for this idea.

You can now add a special flag (-Z or --streaming) to the sender, which
makes it retransmit HELLO packets during the transmission, which
receivers can then use to "jump onto" the ongoing transmission.

Regards,

Alain



From alain at knaff.lu  Tue Sep  1 23:58:21 2009
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 01 Sep 2009 23:58:21 +0200
Subject: [Udpcast] cast-o-matic
In-Reply-To: <1250197444.16904.10.camel@grouper>
References: <1250197444.16904.10.camel@grouper>
Message-ID: <4A9D98FD.9080003@knaff.lu>

Tom Carpenter wrote:
> There's no option to choose the forcedeth module
> on the current cast-o-matic web site; is that
> intentional? I did find it in the .deb package
> containting the 2.6.30 pre-compiled kernel and modules.
> 
> -Tom C.

Indeed, this came missing, no idea why. I now added it back.

Regards,

Alain



From alain at knaff.lu  Wed Sep  2 00:02:33 2009
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 02 Sep 2009 00:02:33 +0200
Subject: [Udpcast] Creating files within dhcp.script
In-Reply-To: <76ce20420908241433s65ced43cs3e012ccd1e248556@mail.gmail.com>
References: <76ce20420908241433s65ced43cs3e012ccd1e248556@mail.gmail.com>
Message-ID: <4A9D99F9.9030604@knaff.lu>

Jens Breuer wrote:
> Hello List,
> hello Alain,
> 
> I am playing around with the "udpcast image generator" and I need to
> store the next-server address in the filesystem for later processing.
> I am using kernel-udpcast_2.6.30-rc5_all.deb and
> udpcast-mkimage_20081213_all.deb.
> 
> This is what my dhcp.script looks like:
> === snip ===
> #!/bin/sh
> 
> [ -n "$broadcast" ] && BROADCAST="broadcast $broadcast"
> [ -n "$subnet" ] && NETMASK="netmask $subnet"
> case "$1" in
>         deconfig)
>                 /sbin/ifconfig $interface 0.0.0.0
>                 ;;
>         renew|bound)
>                 /sbin/ifconfig $interface $ip $BROADCAST $NETMASK
>                 /sbin/echo $siaddr > /etc/server.ip
> 		;;
> esac
> === snap ===
> 
> This works as expected when generating cd-images.
> If I generate a initrd and boot via PXE, the file /etc/server.ip never
> gets created.
> I tried to create the file in many places (/tmp, /sbin, etc.) but it
> doesn't work.
> 
> Is there something important that I am missing?
> I thought that there is no difference between a cd-image and a plain
> initrd (besides syslinux/pxelinux and the kernel being separate).

Exactly. PXE and CD initrd's are the same. Only the floppy initrd is
different (in order to fit into a smaller size).

In which directory do you put the script on CD?

> Additionally FYI, when using the latest kernel and mkimage I get some
> weird behaviour.
> I use VirtualBox 2.2 for testing purposes and both cd-image and initrd
> crash the VM when trying to write to the filesystem from within
> dhcp.script.

Personally, I use kvm, and it works like a charm!

> Any help/suggestion is much appreciated.
> 
> Thanks in advance.
> 
> Regards
> Jens

Regards,

Alain



From cevhers at gmail.com  Wed Sep  2 08:01:47 2009
From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=)
Date: Wed, 2 Sep 2009 09:01:47 +0300
Subject: [Udpcast] using async and pointopoint options together
In-Reply-To: <4A9D9427.5000802@knaff.lu>
References: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>
	<4A9C499E.1060805@knaff.lu>
	<803a75c30908312251m39dd8bfg60c49466b9f641ee@mail.gmail.com>
	<4A9CCC0E.3000005@knaff.lu>
	<803a75c30909010700g5aedf1bk63ff3b7107ef6c7d@mail.gmail.com>
	<4A9D9427.5000802@knaff.lu>
Message-ID: <803a75c30909012301n4f969b1cn8ebc13a41843b34f@mail.gmail.com>

>
> You can specify an address to use to listen for the HELLO packet
> (--mcast-rdv-address option), which itself will then contain a suggested
> address for the multicast transfer.
>
>
But there won't be any HELLO message coming from the sending side since the
sender is another application other than udp-sender. Does it mean that
sending side should provide HELLO messages with the same format as
udp-sender ?


> If your machine has more than one ethernet card, you may also pick which
> card to use using the -i option. This influences the unicast adress that
> the receiver uses.
>
>
As far as I know, by default, udp-receiver listens for its unicast address
as well. Is udp-receiver capable of listening every UDP packet coming to its
port numbered 9000 without expecting any HELLO message from the other side ?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.udpcast.linux.lu/pipermail/udpcast/attachments/20090902/1c351519/attachment.html>

From alain at knaff.lu  Wed Sep  2 08:06:09 2009
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 02 Sep 2009 08:06:09 +0200
Subject: [Udpcast] using async and pointopoint options together
In-Reply-To: <803a75c30909012301n4f969b1cn8ebc13a41843b34f@mail.gmail.com>
References: <803a75c30908120254v1f43c212vc1daf2f1639e4d85@mail.gmail.com>	
	<4A9C499E.1060805@knaff.lu>	
	<803a75c30908312251m39dd8bfg60c49466b9f641ee@mail.gmail.com>	
	<4A9CCC0E.3000005@knaff.lu>	
	<803a75c30909010700g5aedf1bk63ff3b7107ef6c7d@mail.gmail.com>	
	<4A9D9427.5000802@knaff.lu>
	<803a75c30909012301n4f969b1cn8ebc13a41843b34f@mail.gmail.com>
Message-ID: <4A9E0B51.9020702@knaff.lu>

Selçuk Cevher wrote:
>> You can specify an address to use to listen for the HELLO packet
>> (--mcast-rdv-address option), which itself will then contain a suggested
>> address for the multicast transfer.
>>
>>
> But there won't be any HELLO message coming from the sending side since the
> sender is another application other than udp-sender. Does it mean that
> sending side should provide HELLO messages with the same format as
> udp-sender ?

Yes, obviously. It's the same thing as with ftp: If your ftp client does
not know how to handle control and data connection, it can't connect to
the server...

>> If your machine has more than one ethernet card, you may also pick which
>> card to use using the -i option. This influences the unicast adress that
>> the receiver uses.
>>
>>
> As far as I know, by default, udp-receiver listens for its unicast address
> as well. Is udp-receiver capable of listening every UDP packet coming to its
> port numbered 9000 without expecting any HELLO message from the other side ?
> 
> Thanks.
> 

No, the HELLO packet is an integral part of the protocol. Just like ftp
can't do without a control connection, udpcast can't do without HELLO.

Regards,

Alain


From jorgem at enigma.det.uvigo.es  Wed Sep  2 10:33:07 2009
From: jorgem at enigma.det.uvigo.es (=?ISO-8859-1?Q?Jorge_Mu=F1oz_Casta=F1er?=)
Date: Wed, 02 Sep 2009 10:33:07 +0200
Subject: [Udpcast] Udpcast for streaming data.
In-Reply-To: <4A9D957C.4090509@knaff.lu>
References: <4A673FFC.2090609@enigma.det.uvigo.es> <4A6D9D6B.90205@knaff.lu>
	<4A9D957C.4090509@knaff.lu>
Message-ID: <4A9E2DC3.1040404@enigma.det.uvigo.es>

Alain Knaff escribió:
> Alain Knaff wrote:
>   
>> On 07/22/09 18:36, Jorge Muñoz Castañer wrote:
>>     
>>> Hi list,
>>>
>>> I was looking for a tool to send a stream of data with FEC where the 
>>> client/receiver can connect even if the stream has yet begun. I haven't 
>>> found anything but Udpcast that can do anything similar. I think that 
>>> maybe an "streaming" option can be added so the sender sends Hello 
>>> packets at the end of a block of slices+FEC so a receiver can hook to 
>>> the UDP stream.
>>>
>>> What do you think about this? Can this be made modifying Udpcast without 
>>> broken it all? Is there another software that I can use?
>>>
>>> Greetings,
>>>
>>> Jorge M
>>>
>>>       
>> Sounds like a good idea. I'll consider adding this for the next version.
>>
>> Regards,
>>
>> Alain
>>     
>
> I just released version 20090830, which has support for this idea.
>
> You can now add a special flag (-Z or --streaming) to the sender, which
> makes it retransmit HELLO packets during the transmission, which
> receivers can then use to "jump onto" the ongoing transmission.
>
> Regards,
>
> Alain
>
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
>   
Hi Alain,

Sounds great! Thanks Alain. I'll test it and tell you anything.

Jorge M

-- 
---------------------------------------
         Jorge Muñoz Castañer
     e-mail: jorgem(en)det.uvigo.es
  Grupo de Tecnologías de la Información
   Departamento de Ingeniería Telemática
           Universidad de Vigo
          ETSI Telecomunicación
         Campus 36310 Vigo SPAIN
----------------------------------------



From jorgem at enigma.det.uvigo.es  Wed Sep  2 12:19:29 2009
From: jorgem at enigma.det.uvigo.es (=?ISO-8859-1?Q?Jorge_Mu=F1oz_Casta=F1er?=)
Date: Wed, 02 Sep 2009 12:19:29 +0200
Subject: [Udpcast] Udpcast for streaming data.
In-Reply-To: <4A9E2DC3.1040404@enigma.det.uvigo.es>
References: <4A673FFC.2090609@enigma.det.uvigo.es>
	<4A6D9D6B.90205@knaff.lu>	<4A9D957C.4090509@knaff.lu>
	<4A9E2DC3.1040404@enigma.det.uvigo.es>
Message-ID: <4A9E46B1.7040307@enigma.det.uvigo.es>

Jorge Muñoz Castañer escribió:
> Alain Knaff escribió:
>   
>> Alain Knaff wrote:
>>   
>>     
>>> On 07/22/09 18:36, Jorge Muñoz Castañer wrote:
>>>     
>>>       
>>>> Hi list,
>>>>
>>>> I was looking for a tool to send a stream of data with FEC where the 
>>>> client/receiver can connect even if the stream has yet begun. I haven't 
>>>> found anything but Udpcast that can do anything similar. I think that 
>>>> maybe an "streaming" option can be added so the sender sends Hello 
>>>> packets at the end of a block of slices+FEC so a receiver can hook to 
>>>> the UDP stream.
>>>>
>>>> What do you think about this? Can this be made modifying Udpcast without 
>>>> broken it all? Is there another software that I can use?
>>>>
>>>> Greetings,
>>>>
>>>> Jorge M
>>>>
>>>>       
>>>>         
>>> Sounds like a good idea. I'll consider adding this for the next version.
>>>
>>> Regards,
>>>
>>> Alain
>>>     
>>>       
>> I just released version 20090830, which has support for this idea.
>>
>> You can now add a special flag (-Z or --streaming) to the sender, which
>> makes it retransmit HELLO packets during the transmission, which
>> receivers can then use to "jump onto" the ongoing transmission.
>>
>> Regards,
>>
>> Alain
>>
>> _______________________________________________
>> Udpcast mailing list
>> Udpcast at udpcast.linux.lu
>> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
>>   
>>     
> Hi Alain,
>
> Sounds great! Thanks Alain. I'll test it and tell you anything.
>
> Jorge M
>
>   
Hi again,

It works great. We are using UDPCAST to send multimedia data that can be 
played from any point of the stream so the "streaming" option is very 
near of what we need. We also use the Asynchronous mode in order to 
avoid great latency.

There may be another functionality that can be useful with this option. 
If the FEC correction is not enough to correct a slice udp-receiver 
stops. This is useful when you are transmiting data files where there 
must be integrity, but in most multimedia streamings it is not very 
important to loss a small percentage of packets. Can I suggest a 
"multimedia" option which keeps udp-receiver active even if there are 
unrecoverable slices?. These slices can be marked as "no recovered" in 
the receiver slices queue and are not written in the output file or 
fifo. What do you think?

Regards,

Jorge M

-- 
---------------------------------------
         Jorge Muñoz Castañer
     e-mail: jorgem(en)det.uvigo.es
  Grupo de Tecnologías de la Información
   Departamento de Ingeniería Telemática
           Universidad de Vigo
          ETSI Telecomunicación
         Campus 36310 Vigo SPAIN
----------------------------------------



From david.gnedt at platinumzone24.at  Thu Sep 10 20:15:39 2009
From: david.gnedt at platinumzone24.at (David Gnedt)
Date: Thu, 10 Sep 2009 20:15:39 +0200
Subject: [Udpcast] Udpcast 20090830 and gzip'ed data
Message-ID: <4AA9424B.8060900@platinumzone24.at>

Hi,

First I want to thank you for that great piece of software.
I am using Udpcast in the opensource cloning solution OpenClone
(http://openclone.nongnu.org/).

When testing the new Udpcast version 20090830, I discovered a bug.
If I try to transmit gzip'ed data with this version, the receiver breaks
the transfer after a very short period of time (usually less than a second).

For example:

$ udp-receiver -f /dev/null
Udp-receiver 2009-08-30
UDP receiver for /dev/null at 10.10.10.254 on eth1:0
received message, cap=00000009
Connected as #0 to 10.10.10.194
Listening to multicast on 234.10.10.194
Press any key to start receiving data!
bytes=      98 304  (  6.17 Mbps)
Bad base 98304, not multiple of block size 1456
Transfer complete.

$ gzip < /dev/urandom | udp-sender
Udp-sender 2009-08-30
Using full duplex mode
Using mcast address 234.10.10.194
UDP sender for (stdin) at 10.10.10.194 on eth0
Broadcasting control to 10.10.10.255
New connection from 10.10.10.254  (#0) 00000009
Ready. Press any key to start sending data.
Starting transfer: 00000009
Disconnecting #0 (10.10.10.254)
bytes=      98 304  re-xmits=0000000 (  0.0%) slice=0112 -   0
Transfer complete.

Udpcast version 20081213 hadn't any problems with gzip'ed data.

David Gnedt


From alain at knaff.lu  Sat Sep 12 13:41:38 2009
From: alain at knaff.lu (Alain Knaff)
Date: Sat, 12 Sep 2009 13:41:38 +0200
Subject: [Udpcast] Udpcast 20090830 and gzip'ed data
In-Reply-To: <4AA9424B.8060900@platinumzone24.at>
References: <4AA9424B.8060900@platinumzone24.at>
Message-ID: <4AAB88F2.6020108@knaff.lu>

David Gnedt wrote:
> Hi,
> 
> First I want to thank you for that great piece of software.
> I am using Udpcast in the opensource cloning solution OpenClone
> (http://openclone.nongnu.org/).
> 
> When testing the new Udpcast version 20090830, I discovered a bug.
> If I try to transmit gzip'ed data with this version, the receiver breaks
> the transfer after a very short period of time (usually less than a second).
> 
> For example:
> 
> $ udp-receiver -f /dev/null
> Udp-receiver 2009-08-30
> UDP receiver for /dev/null at 10.10.10.254 on eth1:0
> received message, cap=00000009
> Connected as #0 to 10.10.10.194
> Listening to multicast on 234.10.10.194
> Press any key to start receiving data!
> bytes=      98 304  (  6.17 Mbps)
> Bad base 98304, not multiple of block size 1456
> Transfer complete.
> 
> $ gzip < /dev/urandom | udp-sender
> Udp-sender 2009-08-30
> Using full duplex mode
> Using mcast address 234.10.10.194
> UDP sender for (stdin) at 10.10.10.194 on eth0
> Broadcasting control to 10.10.10.255
> New connection from 10.10.10.254  (#0) 00000009
> Ready. Press any key to start sending data.
> Starting transfer: 00000009
> Disconnecting #0 (10.10.10.254)
> bytes=      98 304  re-xmits=0000000 (  0.0%) slice=0112 -   0
> Transfer complete.
> 
> Udpcast version 20081213 hadn't any problems with gzip'ed data.
> 
> David Gnedt
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast

Actually, the problem happened for all kind of data read from a pipe
(not just compressed). This is now fixed in 20090912

Regards,

Alain



From bert.vanvreckem at gmail.com  Mon Sep 14 14:13:08 2009
From: bert.vanvreckem at gmail.com (Bert Van Vreckem)
Date: Mon, 14 Sep 2009 14:13:08 +0200
Subject: [Udpcast] SATA driver
Message-ID: <b8248e300909140513h5353d6a2g183d0bd6623aaae5@mail.gmail.com>

Hello,

I'm trying to build a UDPCast image for a classroom of Dell Optiplex
760 machines. This machine has SATA drives that need the ata_generic
and pata_acpi kernel modules. These don't appear in the menu, but
apparently the actual modules are included in the standard ISO image.
How can I get the correct modules loaded?

Cheers,

bert


From jice at wink.com  Wed Sep 16 04:21:20 2009
From: jice at wink.com (John Eisenman)
Date: Tue, 15 Sep 2009 19:21:20 -0700
Subject: [Udpcast] Experiencing reproducible corruption when using
	udpcast-20090912
Message-ID: <4AB04BA0.8030804@wink.com>

I'm new to udpcast and so may be doing something wrong.  However, I find
that with the latest two versions (udpcast-20090912 or
udpcast-20090830), I experience repeated file corruption.  I've had
better, but not perfect,  success with an old version (udpcast-20071228).

In order to test, I made an ordered file, 500MB in size:

cl6 tmp # ls -l test-52428800.dat
-rw-r--r-- 1 jice jice 524288000 Sep 15 17:52 test-52428800.dat
cl6 tmp # head -14 test-52428800.dat
000000000
000000001
000000002
000000003
000000004
000000005
000000006
000000007
000000008
000000009
000000010
000000011
000000012
000000013

I find that every time I send and receive a file, it is the correct
length.  However, certain data is missing and other data is repeated.  

Here is an example of my command line to send the data:

udp-sender --log udpcast.log --bw-period 1 --nokbd --min-receivers 1
--min-wait 5 --portbase 9010 -f test-52428800.dat --pointopoint

Here is my command line to receive data:

udp-receiver  -f test2 --nokbd --portbase 9010

I have test result files that I can provide if they would be helpful.

I am running under Gentoo on AMD64 processors.  I've tried under two
different kernels:

# uname -a
Linux cl7 2.6.20-gentoo-r8 #1 SMP PREEMPT Wed Aug 22 14:28:25 PDT 2007
x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux

# uname -a
Linux m231 2.6.30-gentoo-r4pb #2 SMP Thu Aug 27 18:41:51 PDT 2009 x86_64
Quad-Core AMD Opteron(tm) Processor 2374 HE AuthenticAMD GNU/Linux




From jice at wink.com  Wed Sep 16 06:58:32 2009
From: jice at wink.com (John Eisenman)
Date: Tue, 15 Sep 2009 21:58:32 -0700
Subject: [Udpcast] Experiencing reproducible corruption when using
	udpcast-20090912
In-Reply-To: <4AB04BA0.8030804@wink.com>
References: <4AB04BA0.8030804@wink.com>
Message-ID: <4AB07078.2010304@wink.com>

John Eisenman wrote:
> I'm new to udpcast and so may be doing something wrong.  However, I find
> that with the latest two versions (udpcast-20090912 or
> udpcast-20090830), I experience repeated file corruption.  I've had
> better, but not perfect,  success with an old version (udpcast-20071228).
>
> In order to test, I made an ordered file, 500MB in size:
>
> cl6 tmp # ls -l test-52428800.dat
> -rw-r--r-- 1 jice jice 524288000 Sep 15 17:52 test-52428800.dat
> cl6 tmp # head -14 test-52428800.dat
> 000000000
> 000000001
> 000000002
> 000000003
> 000000004
> 000000005
> 000000006
> 000000007
> 000000008
> 000000009
> 000000010
> 000000011
> 000000012
> 000000013
>
> I find that every time I send and receive a file, it is the correct
> length.  However, certain data is missing and other data is repeated.  
>
> Here is an example of my command line to send the data:
>
> udp-sender --log udpcast.log --bw-period 1 --nokbd --min-receivers 1
> --min-wait 5 --portbase 9010 -f test-52428800.dat --pointopoint
>
> Here is my command line to receive data:
>
> udp-receiver  -f test2 --nokbd --portbase 9010
>
> I have test result files that I can provide if they would be helpful.
>
> I am running under Gentoo on AMD64 processors.  I've tried under two
> different kernels:
>
> # uname -a
> Linux cl7 2.6.20-gentoo-r8 #1 SMP PREEMPT Wed Aug 22 14:28:25 PDT 2007
> x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux
>
> # uname -a
> Linux m231 2.6.30-gentoo-r4pb #2 SMP Thu Aug 27 18:41:51 PDT 2009 x86_64
> Quad-Core AMD Opteron(tm) Processor 2374 HE AuthenticAMD GNU/Linux
>
>
>
>   
Additional information:

By running in async mode (and setting an fec), I find that I am able to 
produce a non-corrupt output file.  Perhaps this provides a clue as to 
the source of the problem.







From henrique.rodrigues at ist.utl.pt  Wed Sep 16 14:00:21 2009
From: henrique.rodrigues at ist.utl.pt (Henrique Rodrigues)
Date: Wed, 16 Sep 2009 13:00:21 +0100
Subject: [Udpcast] UDP Cast ready-made boot images and i686 issues
In-Reply-To: <4974ACA9.3050000@knaff.lu>
References: <875c3252d3a9566981b3eb58ee39adcf.squirrel@webmail.sodki.org>
	<4974ACA9.3050000@knaff.lu>
Message-ID: <4AB0D355.4090407@ist.utl.pt>


On Mon, January 19, 2009 17:39, Alain Knaff wrote:
> Henrique Rodrigues wrote:
>> Hello,
>>
>> I've been using UDP Cast extensively for a while now and I love it, but
>> I
>> had an issue last week and I want to share it witou you.
>>
>> The UDP Cast website provides handy ready-made boot images. Apparently,
>> those images are compiled for i686 and I couldn't make them work on an
>> older machine because the processor doesn't implement the CMOV
>> operation.
>> The problem seem to belong to GCC, because it thinks that every i686
>> processor implements the optional CMOV operation, which is not true.
>>
>> I solved the problem by compiling my own UDP Cast kernel, but I suggest
>> that the next UDP Cast ready-made boot images drop the i686 requirement
>> and stick to i386, for compatibility reasons.
>>
>> Is this a reasonable request?
>>
>> Thank you and best regards,
>>
>> Henrique Rodrigues
>>
>
> I'll take note of this for the next release
>
> Alain


Hello,

I just want to remind that this is still a problem. The issue can be
reproduced with QEMU. Example:

$ qemu -cpu 486 -boot d -cdrom /home/hmr/udpcd.iso

With my custom kernel, compiled for i386, it works fine.

Best regards,
Henrique Rodrigues

-- 
Henrique Rodrigues
http://sodki.org
Engenharia Informatica e de Computadores - Instituto Superior Tecnico


From jice at mylife.com  Thu Sep 17 10:09:25 2009
From: jice at mylife.com (John Eisenman)
Date: Thu, 17 Sep 2009 01:09:25 -0700
Subject: [Udpcast] Experiencing reproducible corruption when
	using	udpcast-20090912
In-Reply-To: <4AB07078.2010304@wink.com>
References: <4AB04BA0.8030804@wink.com> <4AB07078.2010304@wink.com>
Message-ID: <4AB1EEB5.4030004@mylife.com>

John Eisenman wrote:
> John Eisenman wrote:
>   
>> I'm new to udpcast and so may be doing something wrong.  However, I find
>> that with the latest two versions (udpcast-20090912 or
>> udpcast-20090830), I experience repeated file corruption.  I've had
>> better, but not perfect,  success with an old version (udpcast-20071228).
>>
>> In order to test, I made an ordered file, 500MB in size:
>>
>> cl6 tmp # ls -l test-52428800.dat
>> -rw-r--r-- 1 jice jice 524288000 Sep 15 17:52 test-52428800.dat
>> cl6 tmp # head -14 test-52428800.dat
>> 000000000
>> 000000001
>> 000000002
>> 000000003
>> 000000004
>> 000000005
>> 000000006
>> 000000007
>> 000000008
>> 000000009
>> 000000010
>> 000000011
>> 000000012
>> 000000013
>>
>> I find that every time I send and receive a file, it is the correct
>> length.  However, certain data is missing and other data is repeated.  
>>
>> Here is an example of my command line to send the data:
>>
>> udp-sender --log udpcast.log --bw-period 1 --nokbd --min-receivers 1
>> --min-wait 5 --portbase 9010 -f test-52428800.dat --pointopoint
>>
>> Here is my command line to receive data:
>>
>> udp-receiver  -f test2 --nokbd --portbase 9010
>>
>> I have test result files that I can provide if they would be helpful.
>>
>> I am running under Gentoo on AMD64 processors.  I've tried under two
>> different kernels:
>>
>> # uname -a
>> Linux cl7 2.6.20-gentoo-r8 #1 SMP PREEMPT Wed Aug 22 14:28:25 PDT 2007
>> x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux
>>
>> # uname -a
>> Linux m231 2.6.30-gentoo-r4pb #2 SMP Thu Aug 27 18:41:51 PDT 2009 x86_64
>> Quad-Core AMD Opteron(tm) Processor 2374 HE AuthenticAMD GNU/Linux
>>
>>
>>
>>   
>>     
> Additional information:
>
> By running in async mode (and setting an fec), I find that I am able to 
> produce a non-corrupt output file.  Perhaps this provides a clue as to 
> the source of the problem.
>
>
>   
Another odd clue.  The corruption appears to depend on running the 
udp-sender (udpcast-20090912) as root.  When running the udp-sender as 
another user, there is no corruption. 

Yes, quite odd.  But, does it ring any bells?




From alain at knaff.lu  Mon Sep 21 08:03:39 2009
From: alain at knaff.lu (Alain Knaff)
Date: Mon, 21 Sep 2009 08:03:39 +0200
Subject: [Udpcast] Experiencing reproducible corruption
	when	using	udpcast-20090912
In-Reply-To: <4AB1EEB5.4030004@mylife.com>
References: <4AB04BA0.8030804@wink.com> <4AB07078.2010304@wink.com>
	<4AB1EEB5.4030004@mylife.com>
Message-ID: <4AB7173B.1030802@knaff.lu>

John Eisenman wrote:
> John Eisenman wrote:
>> John Eisenman wrote:
>>   
>>> I'm new to udpcast and so may be doing something wrong.  However, I find
>>> that with the latest two versions (udpcast-20090912 or
>>> udpcast-20090830), I experience repeated file corruption.  I've had
>>> better, but not perfect,  success with an old version (udpcast-20071228).
>>>
>>> In order to test, I made an ordered file, 500MB in size:
>>>
>>> cl6 tmp # ls -l test-52428800.dat
>>> -rw-r--r-- 1 jice jice 524288000 Sep 15 17:52 test-52428800.dat
>>> cl6 tmp # head -14 test-52428800.dat
>>> 000000000
>>> 000000001
>>> 000000002
>>> 000000003
>>> 000000004
>>> 000000005
>>> 000000006
>>> 000000007
>>> 000000008
>>> 000000009
>>> 000000010
>>> 000000011
>>> 000000012
>>> 000000013
>>>
>>> I find that every time I send and receive a file, it is the correct
>>> length.  However, certain data is missing and other data is repeated.  
>>>
>>> Here is an example of my command line to send the data:
>>>
>>> udp-sender --log udpcast.log --bw-period 1 --nokbd --min-receivers 1
>>> --min-wait 5 --portbase 9010 -f test-52428800.dat --pointopoint
>>>
>>> Here is my command line to receive data:
>>>
>>> udp-receiver  -f test2 --nokbd --portbase 9010
>>>
>>> I have test result files that I can provide if they would be helpful.
>>>
>>> I am running under Gentoo on AMD64 processors.  I've tried under two
>>> different kernels:
>>>
>>> # uname -a
>>> Linux cl7 2.6.20-gentoo-r8 #1 SMP PREEMPT Wed Aug 22 14:28:25 PDT 2007
>>> x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux
>>>
>>> # uname -a
>>> Linux m231 2.6.30-gentoo-r4pb #2 SMP Thu Aug 27 18:41:51 PDT 2009 x86_64
>>> Quad-Core AMD Opteron(tm) Processor 2374 HE AuthenticAMD GNU/Linux
>>>
>>>
>>>
>>>   
>>>     
>> Additional information:
>>
>> By running in async mode (and setting an fec), I find that I am able to 
>> produce a non-corrupt output file.  Perhaps this provides a clue as to 
>> the source of the problem.
>>
>>
>>   
> Another odd clue.  The corruption appears to depend on running the 
> udp-sender (udpcast-20090912) as root.  When running the udp-sender as 
> another user, there is no corruption. 
> 
> Yes, quite odd.  But, does it ring any bells?

There was indeed an issue introduced together with the recent support
for "streaming" mode. This is now fixed in 20090920.

Regards,

Alain


From breuer.jens at googlemail.com  Mon Sep 21 22:33:12 2009
From: breuer.jens at googlemail.com (Jens Breuer)
Date: Mon, 21 Sep 2009 22:33:12 +0200
Subject: [Udpcast] Creating files within dhcp.script
In-Reply-To: <4A9D99F9.9030604@knaff.lu>
References: <76ce20420908241433s65ced43cs3e012ccd1e248556@mail.gmail.com>
	<4A9D99F9.9030604@knaff.lu>
Message-ID: <76ce20420909211333s4d30ce94qfeda36e8b4860812@mail.gmail.com>

> In which directory do you put the script on CD?

I just edited the existing script under
/usr/lib/udpcast/tmpl/bin

> Personally, I use kvm, and it works like a charm!

I got my hands onto some real hardware lately and to me it appears as
if I was on the completely wrong track.
It seems as if it has nothing to do with writing to the filesystem but
with the network driver.

If I take a plain initrd created with cast-o-matic without
preconfiguration everything works as expected.

However, if I use cast-o-matic to preconfigure the initrd and set the
network driver to AUTO VirtualBox keeps crashing as described above.
On the real hardware the system hangs for a few minutes then
udpcdialog tells me:
=== snip ===
ifconfig: ioctl 0x8914 failed: No such file or directory
=== snap ===
At the same time in syslog (last line):
=== snip ===
<3>e100: eth0: e100_request_firmware: Failed to load firmware
"e100/d102e_ucode.bin": -2
=== snap ===
What puzzles me here, is that in syslog it says eth0 but in udpcdialog
(not preconfigured) I can see that eth1 is the active interface.

The error message in udpcdialog presents me an OK-button. If I click
it, I am prompted to enter an IP in the next screen. If I chose "Back"
there, I can chose whether to use dhcp or enter an IP manually. If I
chose dhcp everything is back to normal and I can continue to go
through the menu system.

The same goes for initrds created with makeImage. As long as I do not
do any preconfig everything works fine. If I preconfigure udpcdialog
and change nothing else I get the scenario described above.
Even if I explicitly preconfigure the driver to be used (e100) I face the error.
By now I am using the latest udpcast (20090920).

The system has two ethernet cards where one is connected to LAN and
the other not.

To be honest I am completely clueless where the solution of this
problem resides.
Additionally I do not know what further information might be needed to
track the problem down.
If you need any further information please do not hessitate to ask. I
will provide information immediately.

Thank you.

Jens


From breuer.jens at googlemail.com  Tue Sep 22 13:03:48 2009
From: breuer.jens at googlemail.com (Jens Breuer)
Date: Tue, 22 Sep 2009 13:03:48 +0200
Subject: [Udpcast] Creating files within dhcp.script
In-Reply-To: <76ce20420909211333s4d30ce94qfeda36e8b4860812@mail.gmail.com>
References: <76ce20420908241433s65ced43cs3e012ccd1e248556@mail.gmail.com>
	<4A9D99F9.9030604@knaff.lu>
	<76ce20420909211333s4d30ce94qfeda36e8b4860812@mail.gmail.com>
Message-ID: <76ce20420909220403t75c2bab1icea2bcc310dafa89@mail.gmail.com>

Hello all,

sorry for double posting.

I just tested with a different hardware which has only one NIC and it
worked flawlessly.

I suppose that the problem is somewhat related to the presence of two NICs.

However, I don't have a clue how to work around that problem as
disabling one NIC is not an option.

Regards
Jens


From motchane at iut-orsay.fr  Tue Sep 22 20:14:01 2009
From: motchane at iut-orsay.fr (motchane at iut-orsay.fr)
Date: Tue, 22 Sep 2009 20:14:01 +0200
Subject: [Udpcast] performance problem
Message-ID: <200909222014.01563.motchane@iut-orsay.fr>


Hello,

I have a performance problem with udpcast :

- when I send data from one machine s to 2 machines r1 and r2 (all are 
connected with the same switch, all 1000M network card) with : 
udp-sender   --full-duplex --min-clients 2 --max-wait 300 --interface 
eth0 --mcast-all-addr 224.0.0.1 --portbase 2232 --ttl --file /home/test
udp-receiver --mcast-all-addr 224.0.0.1 --portbase 2232 --ttl 1 > /dev/null

I have a bit rate of 9.47 Mbps.

-when I send data from s to either r1 or r2 with the same commands, I obtain  
945.55 Mbps !

I use the last version of udpcast (udpcast-20090920) and Debian Lenny.


Do you have any idea of why and how to solve this ?

Regards,