> For something that must work when things are blowing up, I'm not > overly fond of not hardcoding the address.. But the source is there > so it might come down to whoever implements the best version :) > > Having a network console when you don't have serial or a monitor makes > a lot of sense. And it seems to be the current driving factor behind > network consoles. I'd just like to make it general enough that every > one can have it enabled. > > Traffic wise I don't worry about 1 machine booting up so much as > having 1000 machines on a subnet booting up at nearly the same time. > After a certain point broadcast traffic on a network is just evil. > And if you can avoid it so much the better.
IP multicast has the advantage that some switches (e.g. Cisco, see URL) know what it is, so they limit traffic to ports they know (by snooping the IGMP packets) to be listening. Using a group MAC address with a frame type that switches don't know mean it is forwarded everywhere (like a broadcast) unless the switch can talk be told to set a multicast group with GMRP. There's also the distinct advantage that IP can be routed. How hard is it to get an official IP multicast address somewhat like the NTP address? Presumably a (draft) RFC is needed. With an official address, hardcoding is OK. Although the actual traffic volume probably isn't that great, there may be an inflationary effect in that if it becomes easy to manage and store console logs, then there's more motivation to generate info. :) "Keystroke" traffic in the other direction should be unicast, but if it is essentially just keystrokes it really *is* minimal. The payload protocol would need to have a system identifier to connect to the "right" machine, and preferably crypto authentication, as one normally wants to keep consoles in a locked room. But... this gets me thinking. Why just reproduce a TTY? Better, surely, to encapsulate the things we actually want to do in a protocol like DHCP or SNMP with which one can actually express the concept of e.g. shutdown. There's still definitely a place for ordinary console output for the foreseeable future, but it's worth considering whether we could do something better. At Sychron, we use our own frame type (not for consoles) and send quite a lot of multicasts (actually, we need something which doesn't have a name, a sort of hybrid multicast/anycast). We've had many debates internally about how much broadcast / multicast traffic we can put onto a LAN without frightening the horses. Cisco on L2 multicasts... http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ ovr.htm
