hello, i have a server and client, there are about 50 routers between them and connection type is satellite, i am allowed to use addresses between 224.1.1.1 - 239.1.1.1 and ports between 1000 - 6000 on server, and have a multicasting policy, my all switches configured properly about IGMP Snooping
my problem is i cannot get multicast from clients. here is my log Client Side : $ udp-receiver -f deneme.mpg --portbase 3000 --interface eth1 --mcast-all-addr 224.2.2.1 --nokbd Udp-receiver 2004-05-31 UDP receiver for deneme.mpg at 192.169.132.2 on eth1 received message, cap=00000019 Connected as #0 to 192.168.1.111 Listening to multicast on 232.168.1.111
The Server Side: # udp-sender -f poas.mpg --interface eth1 --ttl 200 --portbase 3000 --mcast-all-addr 224.2.2.1 --nopointopoint Udp-sender 2004-05-31 Using mcast address 232.168.1.111 UDP sender for poas.mpg at 192.168.1.111 on eth1 Broadcasting control to 224.2.2.1 New connection from 192.169.132.2 (#0) 00000019 Ready. Press any key to start sending data. Starting transfer: 00000019 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000 Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
without --nopointopoint parameter it works very fine if using just 1 client, but when i try on multiple client, i can never get the multicast from client. what should i do? any help would be appreciated. Thank you
Sinan Nalkaya wrote:
hello, i have a server and client, there are about 50 routers between them and connection type is satellite, i am allowed to use addresses between 224.1.1.1 - 239.1.1.1 and ports between 1000 - 6000 on server, and have a multicasting policy, my all switches configured properly about IGMP Snooping
The options you want for satellite are --async, --fec, --max-bitrate on the sender, and --nosync on the receiver:
udp-sender -f deneme.mpg --portbase 3000 --mcast-rdv-addr 224.2.2.1 -mcast-data-addr 224.2.2.2 --interface eth1 --async --fec 8x6/64 --max-bitrate 39m
udp-receiver -f deneme.mpg --portbase 3000 --mcast-rdv-addr 224.2.2.1 --nosync --interface dvb0
The --async parameter instructs the sender not to expect anything back from the client (... which would usually not be possible or advisable for a satellite transmission), and --fec instructs the sender to include redundancy (... as the receiver cannot ask for retransmissions, we need a different way of dealing with packet loss)
--fec IxF/N
means "for every N datablocks include F Fec blocks, and use I interleave".
If less (or equal) than N blocks are lost in a fec group, the group may be recovered by use of these redundant blocks.
"Interleave" is meant to offer better protection against burst packet loss (many consecutive packets lost). It works by keeping I fec groups open at once, and alternating among them. So, with I=8 the first packet transmitted will be of group 1, the next of group 2, etc. and the nineth will be group 1 again. The effect of this is that a burst packet loss is spread over many groups. With the parameters above (8x6/64) we can afford to lose 48 packets in a row (which would mean that each of the 8 groups would only lose 6 packets), whereas with no interleave, we would fail at 6.
Higher interleave does need more memory though, and introduces more latency.
Increasing the F/N ratio increases bandwidth needs (more redundancy)
--mcast-rdv-addr sets the "rendez-vous" address, to which the packets are sent that set up the transfer. --mcast-data-addr sets the address of the actual transfer.
N.B. Currently, both addresses cannot be the same, but this will be fixed in one of the next versions.
The --nosync parameter on the receivers instructs udp-receiver not to use synchronous disk writes. This is important as synchronous disk writes may make the receiver temporarily unavailable for some amount of time, and as the async mode on the server effectively switches off flow control, this may lead to interrupted transfers. With --nosync, the probability of such happening is much, much lower.
Regards,
Alain
many thanks for great reply, i should switch to the --async, but in sync mode it seems to be working fine with 2-3 client for now with low block size. Best Regards
-
Alain Knaff -
Sinan Nalkaya