On Sun, 2010-03-28 at 03:42 -0400, Miller, Shao wrote: > Good day Jon, > > In regards to a gPXE 'waitfor <ip> <port> <timeout>' command, I have a > few thoughts: > > If gPXE were to someday support IPv6 or some other network protocol, > would this command be as applicable/relevant? I should think so, just six digits instead of 4 ?
> > It would seem that the <port> option implies that we have some way of > knowing that the <port> is available. Would it make sense to tie <port> > to something that gPXE knows how to use, such as a download protocol or > SAN-boot protocol? Kinda missing the point a bit, "keep it simple stupid". By simply waiting for an valid socket connection it keeps the code very simple. The correct (fat) way is it implement UDP and TCP, do a full challenge response.... but I would have thought the idea is simply to see if the host is up. It could be a ping (ICMP echo) - but as an admin I know it can be a long time between the interface coming up (valid ping replies) and the services being ready. By looking for just a valid socket connect (tcp only) on a port you can either check for a network protocol server or simply look for any old response from the machine. Its also equally valid for any server, windows/linux/any old thing .... > Given that gPXE has a strong focus on small code size for ROM build > targets, could 'waitfor' or other similar use cases be better > implemented in a more generic fashion? Hmmmm I would have thought it was very minimal, I dont know the gpxe code base but I can assume some sort of tcp session code exists, not that a full session is required as the simply the "connect" (accept) is all thats needed, the content would be ignored. > > If the check can be accomplished by repeated download attempts in a > loop, the scripting discussion in the gPXE developers' mailing-list > could potentially come to fruition and accomplish this same behaviour in > a more programmatically generic way, with 'if' and loops, for example. Valid point, maybe a bit less user friendly as more code is required. All OK if the documentation for gpxe scripting is first rate, i've not seen it :-) I would argue 80/20 rule. 80% of people would want the "waitfor" type behaviour, but maybe a little tough on the other 20% ? > As it stands, there are patches not yet committed to the gPXE official > code-base which can accomplish the behaviour of the suggested 'waitfor' > command, if the assumption is that a download trial is roughly the same > as testing for <port>. > > #!gpxe > clear script_errors > dhcp net0 > : test_download > chain http://ip:8080/some_boot_file > sleep 10 > goto test_download > > In the above, 'chain' should not return, but if it does, we wait ten > seconds and retry. The above does not work in current gPXE, but does > work with some of the patches under discussion. In that case could not waitfor simply be a macro within gpxe as all the underlying functions would be in the codebase ? :-D I prefer readable simple functions, the "chain" in the above code does not seem obvious or friendly, also I cant even see how that loop escapes - to me it reads as stuck as "goto" is not conditional? Cheers, Jon _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
