Exiting udp-receiver or reboot machine after a certain amount of time without transfer activity
Hello,
I am curious whether there is an commandline option which could instruct udp-receiver to exit after a certain amount of time without any udp-sender activity or generally when the transfer process doesn't start. At least I could not find anything in the documents.
We use udpcast together with PXE-boot and sometimes some machines are simply not responding to the sender (why is yet unclear). After manually restarting the machines it is usually the case that the machines to be imaged are responding again and everything is well. Unfortunately it could be the case that there are machines to be imaged which are placed in locked rooms and so it is impossible to restart them manually.
Regards Jens
Jens Breuer wrote:
Hello,
I am curious whether there is an commandline option which could instruct udp-receiver to exit after a certain amount of time without any udp-sender activity or generally when the transfer process doesn't start. At least I could not find anything in the documents.
We use udpcast together with PXE-boot and sometimes some machines are simply not responding to the sender (why is yet unclear). After manually restarting the machines it is usually the case that the machines to be imaged are responding again and everything is well. Unfortunately it could be the case that there are machines to be imaged which are placed in locked rooms and so it is impossible to restart them manually.
Regards Jens
The new 20070129 version of udp-receiver now has a --start-timeout option, which allows to specify a timeout, in seconds within which the sender must send a rendez-vous packet, and then the first data packet.
If no rdv packet has been received with n seconds of starting udp-receiver (or if the transmission hasn't started within n seconds of sending the rdv packet), then the receiver aborts.
Once the transmission has started, the receiver continues, even if the server becomes slow afterwards.
Regards,
Alain
On Tue, 30 Jan 2007 02:32:53 +0100, Alain Knaff wrote
The new 20070129 version of udp-receiver now has a --start-timeout option, which allows to specify a timeout, in seconds within which the sender must send a rendez-vous packet, and then the first data packet.
There is a bug in this feature. if you don't add --start-timeout xxxx under "extra udpcast parameters" (or what it is cald) the recever exits right away saying: "Recever error". I don't know if the problem is that the recever dosen't work without it og is the default value is set to 0 sek, but it is a very irritating bug
Greetings Gunner Poulsen
Ps. The new 2.6.19 kernel solved my r8169 problem :-)
Hello List, Hello Alain,
thank you for implementing the feature in the current version. Unfortunately I have to second what Gunner said as it seems that this new feature introduced a weird behaviour. I just tested the new version. I had my initrd build by cast-o-matic and specified as extra command line parameters "--nokbd --start-timeout 600". Additionally I always check the option "Reboot system after udpcast" together with "full featured shell". I waited 10 minutes because I wanted to see what happens when the timeout exceeds and then I saw the following messages on the screen: "Receiver error. Error. Not rebooting."
The machine did not reboot what I don't think is the desired effect.
Regards Jens
Jens Breuer wrote:
Hello List, Hello Alain,
thank you for implementing the feature in the current version. Unfortunately I have to second what Gunner said as it seems that this new feature introduced a weird behaviour. I just tested the new version. I had my initrd build by cast-o-matic and specified as extra command line parameters "--nokbd --start-timeout 600". Additionally I always check the option "Reboot system after udpcast" together with "full featured shell". I waited 10 minutes because I wanted to see what happens when the timeout exceeds and then I saw the following messages on the screen: "Receiver error. Error. Not rebooting."
The machine did not reboot what I don't think is the desired effect.
Regards Jens
Yes, the "reboot" option in cast-o-matic was initially intended to reboot the machine into the installed OS in case of success. However, if --start-timeout is supplied and triggered, udp-receiver returns an error.
I've now added an "unconditional reboot" checkbox to cast-o-matic which should address this issue.
Regards,
Alain
Hello group, This is my first post and wanted to thank everyone and the author(s) for their hard work. I work in the broadcast industry and have been developing Datacast solutions for KET. Well, after seeing this project I realized that this could replace our propitiatory software. The only hurdle is to be able to throttle the output on demand, as the one- way stream and forward error correction system has been implemented. I will get details on the throttling procedures for the group if anyone is interested. The hardware that it needs to talk to is a Logic Innovations IPE (IP Encapsulator) that embeds the IP traffic in the 19.39 Mbit data stream. I can give more info on request. David Crider Special Projects Engineer Kentucky Educational Television
Alain Knaff wrote:
Jens Breuer wrote:
Hello List, Hello Alain,
thank you for implementing the feature in the current version. Unfortunately I have to second what Gunner said as it seems that this new feature introduced a weird behaviour. I just tested the new version. I had my initrd build by cast-o-matic and specified as extra command line parameters "--nokbd --start-timeout 600". Additionally I always check the option "Reboot system after udpcast" together with "full featured shell". I waited 10 minutes because I wanted to see what happens when the timeout exceeds and then I saw the following messages on the screen: "Receiver error. Error. Not rebooting."
The machine did not reboot what I don't think is the desired effect.
Regards Jens
Yes, the "reboot" option in cast-o-matic was initially intended to reboot the machine into the installed OS in case of success. However, if --start-timeout is supplied and triggered, udp-receiver returns an error.
I've now added an "unconditional reboot" checkbox to cast-o-matic which should address this issue.
Regards,
Alain
Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
David Crider wrote:
Hello group, This is my first post and wanted to thank everyone and the author(s) for their hard work. I work in the broadcast industry and have been developing Datacast solutions for KET. Well, after seeing this project I realized that this could replace our propitiatory software. The only hurdle is to be able to throttle the output on demand, as the one- way stream and forward error correction system has been implemented. I will get details on the throttling procedures for the group if anyone is interested. The hardware that it needs to talk to is a Logic Innovations IPE (IP Encapsulator) that embeds the IP traffic in the 19.39 Mbit data stream. I can give more info on request. David Crider Special Projects Engineer Kentucky Educational Television
Right now, you can already set the data transmit rate using the --max-bitrate setting
But probably what you are looking for is a way to dynamically change it during transmission? I'll think about a way to implement that. Maybe by accepting control packets over a second UDP port which contain commands to set bitrate to a new value?
Alain
Yes, dynamically changing the bandwidth through SNMP messages is what I need. I can send you the info on how LI (Logic Innovations) and other IPE manufactures talk to the datacasting computers. This will take me a couple of days as I'll need to contact Logic Innovations first. Thank you for your time and wonderful product and I look forward to sharing with the group the GUI front end and GUI user client that I am using for my applications as soon as its finished.
Alain Knaff wrote:
David Crider wrote:
Hello group, This is my first post and wanted to thank everyone and the author(s) for their hard work. I work in the broadcast industry and have been developing Datacast solutions for KET. Well, after seeing this project I realized that this could replace our propitiatory software. The only hurdle is to be able to throttle the output on demand, as the one- way stream and forward error correction system has been implemented. I will get details on the throttling procedures for the group if anyone is interested. The hardware that it needs to talk to is a Logic Innovations IPE (IP Encapsulator) that embeds the IP traffic in the 19.39 Mbit data stream. I can give more info on request. David Crider Special Projects Engineer Kentucky Educational Television
Right now, you can already set the data transmit rate using the --max-bitrate setting
But probably what you are looking for is a way to dynamically change it during transmission? I'll think about a way to implement that. Maybe by accepting control packets over a second UDP port which contain commands to set bitrate to a new value?
Alain
-
Alain Knaff -
David Crider -
David Crider -
Gunner Poulsen -
Jens Breuer