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
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
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
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
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
Le 9 févr. 10 à 16:19, udpcast-request(a)udpcast.linux.lu a écrit :
>
> Date: Tue, 9 Feb 2010 16:19:44 +0100
> From: Jens Breuer <breuer.jens(a)googlemail.com>
> To: udpcast(a)udpcast.linux.lu
> Subject: Re: [Udpcast] does sender need to bind a socket to the
> multicast addr and receiver (portbase) port ?
> Message-ID:
> <76ce20421002090719j1b354fay54a779bdccf9f0cf(a)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
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-
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