If I open a socket between two computers on the WAN, while at least one of them has a dynamic ip-address, and this address changes even though the socket hasn't been explicitly closed : Do have a warranty that this socket will remain open at least until my program really asks to close it?
Regards
As soon as the IP address of one of the two computers changes then the computer that held on to the original address, (not knowing the new address) would no longer be able to communicate with the other. There is no automatic process of informing the connected clients that a new IP address has been assigned, you could conceivably create one but you would have to communicate the new address over the old IP address before you changed it. Also the other computer wouldn't immediately know that addresses had changed at all, you would have to wait until it timed out. The other big challenge is the likelihood that the computer wouldn't even know that it's own IP address had changed because on a WAN it might be exposed to the internet via a NATed addresses.
Related
I'm not sure I've phrased the question correctly but I'll explain a bit more.
I have a server running on a virtual machine on PC1. I can access this through a particular IP address on the same computer.
Now on a different PC2, when I try the same IP address I see the content served by PC1's server. Both computers are on the same network.
I don't really understand how that IP address is serving the same info on PC2. I'm not sure of the mechanics in the background either and it would really help if someone could explain what's happening here.
If you are using a wifi network then it is because of it you can access the content of the server you have created.
You can see the architecture as that of the internet but on a small scale. Your IP addresses are stores in the wifi (routing tables) so that it can send packets accordingly (See hoping and packet transmission). To be precise, each and every individual system maintains a routing table in it. Thus, in order to fetch a particular site, a system sees its routing table. If the particular IP address is present, the router returns it and the system shows that page. On the contrary, if the IP address is not present the router asks the nearby systems/servers for that particular IP address and the phenomenon continues till the IP address is found.
So, when you search for a local server via system B, whose data is in system A, then the router requests all its child systems to search for the particular IP address in their routing tables, and thus you can access the local server via systems connected on the same network.
To add furthermore, since the local servers are known to be locally operated, the router just sends the seek requests to its child systems only and not globally.
I have tried to keep it as simple as possible supposing that you have not learned about computer networks yet.
From an introduction to Berkeley Sockets API in Tanenbaum's Computer Networks,
On the server side:
Newly created sockets by SOCKET primitive do not have network
addresses. These are assigned using the BIND primitive. Once a
server has bound an address to a socket, remote clients can connect to
it.
The reason for not having the SOCKET call create an address directly
is that some processes care about their addresses (e.g., they have
been using the same address for years and everyone knows this
address), whereas others do not.
Why is not having the SOCKET call create an address directly,
because some processes care about their addresses, whereas others
don't?
On the client side:
Now let us look at the client side. Here, too, a socket must first be
created using the SOCKET primitive, but BIND is not required since
the address used does not matter to the server.
why is BIND not required because the address used does not matter
to the server?
Why is not having the SOCKET call create an address directly, because some processes care about their addresses, whereas others don't?
Basically, because a strict client (eg. web browser) does not care what its local IP address/port is. By not requiring the SOCKET call to create/allocate an address, it can allow for the BIND call to actually never happen in the client context (where it often doesn't matter) but happen in the server context (where it greatly matters).
why is BIND not required because the address used does not matter to the server?
This is related to the first part of the answer above. A socket only needs to be bound to a specific address and port in order for something to reach out and connect to it. In many cases (such as a web browser), there is no reason for anything to be able to connect to it - it only needs to be able to connect to other systems (servers).
To make it a general principle, you only need to BIND a socket to an address when something else will need to connect up to it. You do not need to BIND a socket if it will only be connecting to something else.
Why is not having the SOCKET call create an address directly, because some processes care about their addresses, whereas others don't?
Because that's the way they designed it. Listening sockets don't need a target address, and in most cases they don't need a source address either (INADDR_ANY); and most client sockets don't need a specific source address either. Clients never need to call bind() at all in most cases. So putting the address into the socket creation API would be pointless.
The reason for not having the SOCKET call create an address directly is that some processes care about their addresses (e.g., they have been using the same address for years and everyone knows this address), whereas others do not.
I don't agree with this strange statement.
why is BIND not required because the address used does not matter to the server?
It's another strangely expressed statement. The source address of a connected socket can be determined automatically via the static IP routing tables. As long as the client can connect to the server at all, symmetry guarantess that the server can send back to the client on the same connection, so the actual source-address of the client doesn't matter specifically to either the cleint or the server application. It matters to TCP of course, otherwise it wouldn't exist.
As we know in any web application for a tab in a browser there is one process so we require an ip address and a port number to identify the process. As we know for every tab there is unique port number. So for every process there is unique process id. Also instead of using ip and port number combination can we use ip and process id combination in socket programming. And if so then how? And if not why? Please can you help me.. Sorry for the bad English
Can we use IP address and process id combination instead of IP address and port number?
No.
Why and why not?
Because they didn't define TCP/IP that way. It doesn't make sense. A remote computer doesn't have a way of discovering a process ID on another host. What it needs is a fixed number, i.e. a port number, which both hosts can implement.
As we know for every tab there is unique port number.
This is absolutely and definitely incorrect. 'We' don't 'know' any such thing.
As we know in any web application for a tab in a browser there is one process
That is not guaranteed. That is an implementation detail of the browser. It may or may not use a separate process for each tab.
so we require an ip address and a port number to identify the process.
No, you need an IP address and port to identify a given socket endpoint. A process can have more than one socket active.
As we know for every tab there is unique port number.
That is not guaranteed, either. HTTP is stateless, and connections are not guaranteed or required to stay connected between requests, especially for long periods of time. Say you open a tab and request a given website, leave the tab open for awhile, and then open a new tab to a different website. The previous connection(s) may have been closed while the tab sat idle, and those port(s) may be available for re-use in the new tab.
So for every process there is unique process id.
That is the only thing that is guaranteed in this situation. But remember that once a process ends, its process id can and will be re-used in a subsequent new process.
Also instead of using ip and port number combination can we use ip and process id combination in socket programming.
No. But on some platforms, such as Windows, there are APIs available to discover the process ID that owns a given socket, at least.
if not why?
Because that is not how sockets are designed to operate. A socket endpoint is identified by its protocol/IP/port tuple, and a socket connection is identified by the protocol/IP/port tuple of the two peers that are connected to each other. Remember that a socket connection can span across machine boundaries, but a process ID is only local to the machine it is running on.
I have been working on a local LAN service which uses a multicast port to coordinate several machines. Each machine listens on the multicast port for instructions, and when a certain instruction is received, will send messages directly to other machines.
In other words the multicast port is used to coordinate peer-to-peer UDP messaging.
In practice this works quite well but there is a lingering issue related to correctly setting up these peer-to-peer transmissions. Basically, each machine needs to announce on the multicast port its own IP address, so that other machines know where to send messages when they wish to start a P2P transmission.
I realize that in general the idea of identifying the local IP is not necessarily sensible, but I don't see any other way-- the local receiving IP must be announced one way or another. At least I am not working on the internet, so in general I won't need to worry about NATs, just need to identify the local LAN IP. (No more than 1 hop for the multicast packets is allowed.)
I wanted to, if possible, determine the IP passively, i.e., without sending any messages.
I have been using code that calls getifaddrs(), which returns a linked list of NICs on the machine, and I scan this list for non-zero IP addresses and choose the first one.
In general this has worked okay, but we have had issues where for example a machine with both a wired and wifi connection are active, it will identify the wrong one, and the only work-around we found was to turn off the wifi.
Now, I imagine that a more reliable solution would be to send a message to the multicast telling other machines to report back with the source address of the message; that might allow to identify which IP is actually visible to the other machines on the net. Alternatively maybe even just looking at the multicast loopback message would work.
What do you think, are there any passive solutions to identify which address to use? If not, what's the best active solution?
I'm using POSIX socket API from C. Must work on Linux, OS X, Windows. (For Windows I have been using GetAdapterAddresses().)
Your question about how to get the address so you can advertise it right is looking at it from the wrong side. It's a losing proposition to try to guess what your address is. Better for the other side to detect it itself.
When a listening machine receives a message, it is probably doing do using recvfrom(2). The fifth argument is a buffer into which the kernel will store the address of the peer, if the underlying protocol offers it. Since you are using IP/UDP, the buffer should get filled in with a sockaddr_in showing the IP address of the sender.
I'd use the address on the interface I use to send the announcement multicast message -- on the wired interface announce the wired address and on the wireless interface announce the wireless address.
When all the receivers live on the wired side, they will never see the message on the wireless network.
When there is a bridge between the wired and the wireless network, add a second step in discovery for round-trip time estimation, and include a unique host ID in the announcement packet, so multiple routes to the same host can be detected and the best one chosen.
Also, it may be a good idea to add a configuration option to limit the service to certain interfaces.
What could cause IP-addresses to be different in one computer?
My Perl variable $ENV{'REMOTE_ADDR'} differs all the time. What could cause this to happen?
Most people do not have fixed IP addresses. They may change daily, or when their connection to their ISP is reset, or all the time if they are behind some kind of proxying layer that may route requests through more than one system.
REMOTE_ADDR refers to the client address, so would be different if you have multiple clients.
If you are testing with one client, perhaps your network interface has multiple IP addresses or you're observing this behavior over time when your IP has changed due to DHCP?