I'm blocked on a TCP/IP question. Please help. Thanks.
I'm trying to make multiple-IP hosts work, even in vls-less situations. The following comment in java.net.ServerSocket
/**
* Create a server with the specified port, listen backlog, and
* local IP address to bind to. The bindAddr argument
* can be used on a multi-homed host for a ServerSocket that
* will only accept connect requests to one of its addresses.
* If bindAddr is null, it will default accepting
* connections on any/all local addresses.
* The port must be between 0 and 65535, inclusive.
*
* @param port the local TCP port
* @param backlog the listen backlog
* @param bindAddr the local InetAddress the server will bind to
* @see SocketConstants
* @see SocketOption
* @see SocketImpl
* @see JDK1.1
*/
public ServerSocket(int port, int backlog, InetAddress bindAddr)
led me to suspect that a TCP port number might normally be associated with
a host, rather than an IP-address/host-interface. I just performed a set
of experiments that seemed to confirm that. While putting my laptop in a
multiple-IP configuration, I created a socket in one process not specifying
a bindAddr. From another process, I was able to connect to it using its
port number paired with any of my laptop's IP address, including localhost.
I was using the Microsoft jvm and Win95. Since the surprising connectivity
succeeded, it doesn't sound like this could be a Microsoft jvm bug. Is it
a Win95 bug, or is this proper behavior? What do multiple-IP unix machines do?
A quick answer to this one would really help. I was just about to add
support for multiple IP addresses, but I assumed I'd need a thread to
listen on a socket per IP address. If TCP ports are per-host rather than
per-IP, then each Vat would only need to listen on one socket, as in the
current code. Multiple TCP/IP addresses would still be added to the search
path as listen addresses, but these would all have same port, merely
designating different routes to the same socket. This would be nice, but
what's the real story?
Towards jurisdiction-free commerce, --MarkM