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
I downloaded your CD image and it worked fine until I used it on a pc with a
USB keyboard. These PCs are in the lab I am trying the program on. Do I need
to compile my own image using my own kernal? I am using debian 3.1 and cannot
find the required files as specified by the -k switch.
Please, let me know what I need to do.
Thanks,
AJ
Hello
I use udpcast with several computers. After duplicating one hard disk to the
others, i would like that the computers that received the data reboot
automatically. But i don't know how to do this because udpcast don't allow
us to do that with it's options.
I'm waiting for your advice
Aimé David
_________________________________________________________________
MSN Messenger : personnalisez votre messagerie instantanée !
http://g.msn.fr/FR1001/866
On Mon 8/15/2005 10:25 AM, Alain Knaff wrote:
>Try upgrading to a newer version of ethereal.
>
>I just tried it here: version 0.10.9 has the problem, but 0.10.12
>works fine.
>
>Or use tcpdump...
I have used the lattest version of udpcast (udpcast-20050226.tar.gz) as well as used ethereal version 0.10.12 and I still get the "Bogus IP header length (0, must be at least 20)" I will continue to try this on different Platforms with different network switches and see what I get.
-Lance
>Maybe you could try with the AHCI driver (AHCI SATA low-level driver),
>this is supposed to work with Intel (ICH) chipsets. If that doesn't
>work, try ata_piix (SCSI low-level driver for Intel PIIX/ICH ATA
>controllers).
>
>Both are present on the CD.
>
>Alain
No, that doesn't work =/
I have seen that there is a new support in the new 2.6.1x Kernel for the
new Intel motherboards...
Could you release a new version of your UDP-Cast?
Many thanks :o)
Laurent
Hi all,
It has been a wile since I have been active in this mailing list,
sorry. It is because this software rocks! We love it. The problem I
am seeing is that my high end layer 2 switches do not see the multicast
traffic as such, it sees it as regular IP traffic, I have been working
with the tech support for the switch for about 2 months on this and
finally he is saying it is the softwares fault - I disagree, but am
hoping someone knows something I don't or has seen this same issues.
The switch is a Foundry FastIron 800 running BL3 code with "ip
multicast passive" and "ip pimsm-snooping" enabled (this also enables
igmp-snooping for those that don't have one of these switches). To
make matters more complicated, we have a layer 3 switch that handles the
traffic just fine because it recognizes the multicast IP address, but
since the layer 2 switch can not recognize the IP address it just
Broadcasts it.
I can get an IGMP group to be registered on the Layer 2 switch by
using "-mcast-all-addr" but once the cast starts it doesn't seem to use
that group - or at least the switch doesn't recognize it.
When we do a ethereal capture or a tcpdump, all the multicast traffic
shows up as "Bogus IP header length (0, must be at least 20)" and this
is making the tech with foundry believe it is the softwares fault.
Conclusion: I need to ether have someone give me a way to prove that
the traffic is really multicast traffic, or a way to get the software to
really use the igmp group that it registers.
Any information, ideas, or comments would be helpful.
Thanks,
-Lance Grover
Hello,
We use udp-cast successfully in our firm,
but we have a little problem with our new Intel915G-Boards,
udp-cast doesnt know the new serialATA controller,
could you please update the udp-cast cd, thank you :)
