Hi Alain,
I was studying the UDPCast source code for some experimental purposes. I have the following question.
1. The whole data to be transfered into is divided into slices which again contains a series of blocks to transfer. Can we consider the whole data to be transfered as a single slice ( By setting appropriate parameters in code) and what kind of performance issues we can expect if we do a change of this kind at code level.
Thanks in advance,
Sai
---------------------------------
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
The option of ipappend 1 in the default file and retransmission
of HELLOs in udp-sender (--rexmit-hello-interval) has been
valuable to getting udpcast working with the Dell notebooks
we have with Broadcom 5700 series ethernet.
Today, with a slightly newer broadcom chipset appearing in
the most recent shipment, we noticed that udp-receiver was
intermittantly not showing the "hit any button to start transfer"
message. With some trial and error I found that if I
watched the tail of /var/log/message on the receiver (server)
and waited for the messages on TX and RX flow control to
complete before running udp-receiver, it would always initiate
a good connection. If I had started the udp-receiver
prior to the TX/RX flow control appearing in the message log
(in which case there was no "hit any key" message),
I could ^C the receiver, run it again and it would signify
the ready state with 100% success.
In conclusion, we have a workaround of starting udp-receiver
after a few seconds past the client PXE machine booting and
showing the udp-sender status ready (but not yet "hit any key...").
Another solution would be if udp-receiver also supported
--rexmit-hello-interval. It isn't a flaw in the udpcast system
but a kludge for a network device that is proving itself to be
sluggish in initialization in general.
--Donald Teed
Hi all,
I don't know if this should be applied to the source tree, but perhaps
some people will find this patch useful (I know we do).
We wanted some additional logging from udpcast to debug our casting
sessions, because it seems that the only thing logged to its logfile is
messages like this:
"Doubling slice size to 1024"
We also prefer syslog in stead of the separate file for logging
So I wrote this little patch.
It logs more information (very usefull for udpcast's running in the
background on a image server) and it logs it to syslog.
Information being logged:
* New connections
* Why a cast starts (is min clients reached or max wait passed, etc)
* Transfer start (+ what file,pipe,port,if,participants)
* Transfer complete
* Disconnects
See attached .patch
Kind regards,
--
Ramon Bastiaans
SARA - Academic Computing Services
Kruislaan 415
1098 SJ Amsterdam
Hi!
I'am using udpcast to transfert disk Images from a server to several clients.
The server box has one Network card and several virtual interfaces (eth0, eth0:0, eth0:1...).
When I try to send a file to one client through one of the virtual interface(eth0:x) everything goes well.
But when the client number increases (more than one) I get an error saying:
Rogue packet received <eth0 IP address>:9001 expecting <eth0:x IP address>:9001
The command line used on the server is :
udp-sender --file <filename> --interface eth0:x
On the client:
udp-receiver --file <filename>
It seems that only the eth0 interface can be used bay udpcast. It works perfectly with this one.
How can I get udpcast to work with my virtual interfaces
Sorry for my bad English!
Thank you for your help.
regards
Alex
hello group
i work for a school system and have been using UDPCast for a couple of years
now with great results. but we just got in the new dell gx280 pcs. they have
sata hard drivers and a broadcom gigabit ethernet card. i can not get the boot
disk nor the cd to use either device. is there anyone who has add these
devices to the /dev/ on the floppy or cd image?
(John Allison )
I've joined udpcast and Gentoo's tftpboot Linux environment with
lzop, Busybox, raidtools, etc. to make a solution for booting
Sun Sparc machines on the network and using Udpcast to do
the usual business of cloning disks and partitions.
There is a guide (and related downloads/links) here:
http://www.artistic.ca/dteed/tftpboot-udpcast.htm
This might be useful for those who have wanted to 'boot net'
a Sun sparc and use Udpcast from there.
Enjoy...
--Donald Teed
The documentation I'm finding for DHCP is not very systematic
in its approach. So I'm seeking help on this list...
I'd like to have DHCP point to different PXE boot menus
depending on what subnet the client is coming from.
The config I've tried already is something like this:
subnet 192.168.1.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.1.2 192.168.1.3;
next-server 192.168.1.1;
class "pxe1" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
filename "/pxe1/pxelinux.0"; # Uncomment
}
}
subnet 192.168.2.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.2.3 192.168.2.4;
next-server 192.168.1.1;
class "pxe2" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
filename "/pxe2/pxelinux.0"; # Uncomment
}
}
This isn't exactly the configuration on our live DHCP
server, but it should artificially reproduce the problem I
want to handle, which is making two subnets refer to
the TFTP server.
What I see with this configuration is that one connection
to TFTP goes ahead and boots OK, and then I get errors that
there are "no free leases" available. In this testing
with this configuration, I'm never seeing a client
assigned 192.168.2.*
It behaves as if the match is made and then it cannot
move onto the next subnet block where there is also
a good match.
--Donald Teed
