On Wed, Aug 19, 2009 at 4:45 PM, "Martin v. Löwis" <mar...@v.loewis.de>wrote:
> > No, I just said its conventionally used as that but its not definition > > of a broadcast (in fact you can have any valid host address defined > > as broadcast as long as all members of the network agree on that) > > You could, but then you are violating existing protocol specifications. > > RFC 1122 mandates, in sections 3.2.1.3 and 3.3.6, that certain addresses > MUST be understood as broadcast addresses, by all nodes (independent of > configuration). > > I think a Python IP address library should conform to all relevant RFCs. > Yes, but section 3.3.6 also states: There is a class of hosts (4.2BSD Unix and its derivatives, but not 4.3BSD) that use non-standard broadcast address forms, substituting 0 for -1. All hosts SHOULD recognize and accept any of these non-standard broadcast addresses as the destination address of an incoming datagram. A host MAY optionally have a configuration option to choose the 0 or the -1 form of broadcast address, for each physical interface, but this option SHOULD default to the standard (-1) form. So it sounds like doing what I suggested earlier (default to [-1], allow for customization) is actually required by the RFC :-). Although it does sound like the RFC only requires that you be able to customize to [0] rather than [-1], rather than any address. In practical terms though I believe it is possible to do as Tino suggests and configure any crazy address you want to be the broadcast address (or addresses, even) for a network. I think setting the broadcast address to something else just does not need > to be supported. It is unusual, but frankly, needing to actually do operations on broadcast addresses at all is also a pretty unusual task. Broadcast itself is a somewhat obscure corner of networking. I suspect that in many deployments that need to write significant code to deal with broadcast addresses, rather than the usual default stuff, funky configurations will actually be quite common. I would not be surprised to find that there are still some 4.2BSD VAXes somewhere doing something important, and some Python may one day be called upon to manage their networks.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com