If two processes both use a shared local port to connect to the same remote port of the server server, what happens when the server tries to respond to one? Or is there a mechanism to prevent this?
I assume you're asking about TCP here. When the two processes connect to a single remote port, they will be using different local ports. That is how the server distinguishes the connections. A connection has four parts that uniquely identify it: source port, source IP address, destination port, and destination IP address.
Related
i have a three system connected in a LAN and one of the system has server program running but the client doesnt know IP of that server. Client has to detect that server and connect with that server . Is it possible to do and whether it can be done using TCP/IP
You could probably send a TCP package to the broadcast address of your network when trying to find the servers ip address.
That way every device in your network receives your package. Then just make the server listen and respond to that package. That way you can easily find your servers IP address without trying to connect to every single IP
I have implement a Client-Server application in java. The server can serve multiple clients, and I want to test that, but my knowledges on Networking is poor, and I need a way to test my application on my home.
I have a rooter, which are connected both of my computers. My "server" class in java uses as host the local host (127.0.0.1) on a given port.
How can I test my program if
The Server.java is running on the Computer A
Server.java is running on 127.0.0.1 on 3943 port
1st Client.java is running on the Computer A
1st Client.java is connected to 3943 port
2nd Client.java is running on the Computer B
2nd Client.java is connected to 3943 port
Any ideas?
Use unique ports for the clients and servers running on the same machine. In addition 127.0.0.1 is localhost (internal to that machine). Computer B cannot communicate with 127.0.0.1 on Computer A. Use 127.0.0.1 if all applications or on the same machine. Use the computers actual IP address if you want external machines to be able to communicate with the server.
When client and server, are on the same computer, what you are doing must be already working.
To connect from a different computer, you need to find the "real" ip address of your server.
If you are on Windows, open a command shell on your computer A, and run ipconfig. On unix/linux/mac, run ifconfig.
Look for a string, looking like an ip address, but not 127.0.0.1, there has to be another one if you are connected to a network, probably looks like 10.0.0. or 192.168.<0 or 1> ..
Use this address everywhere instead of 127.0.0.1
A full TCP connection consists of two different endpoints. The server side of the connection is one endpoint (it will be do a listen on that endpoint). When a client creates it's side of the connection (the client socket), it will do a connect to the server ip:port combo and get a number assigned from a range of so-called "ephemeral" ports.
The fact that both sides of the connection have the same IP address doesn't matter - the full connection is defined by two distinct elements (address:port combinations).
FirstClient's connection to the server will be ServerIP:ServerPort<->Client1_IP:Client1_Port, and SecondClient's connection will be ServerIP:ServerPort<->Client2_IP:Client2_Port. The network layer can differentiate between these (they are two different connection streams) and route traffic to the appropriate sender/receiver for that stream.
If you run the server bound to IP 127.0.0.1 you are not opening it to the network, only your own computer will be able to connect to it, acessing 127.0.0.1 (loopback IP address).
To open this server to the network, you must do one of the two things:
Bind it to the IP 0.0.0.0 so it will be acessible from all networks;
Bind it to a specific network IP address so that it will be available to that network only.
Its common practice to just bind it to 0.0.0.0, its easier.
Once its done, you will be able to connect from other computers to the server running on computer A, however, not through IP 127.0.0.1. Thats the loopback address and can only be used by a computer to connect to itself.
Computer A can use the IP 127.0.0.1 to connect to the server since the server is running on it, but other network computers will have to specify computer A's network IP address.
You can find your IP address on the network adapter details, or running the command ipconfig /all on a command prompt (Windows) or ifconfig (Linux).
I am writing a TCP server application using Winsock. The machine on which my server will run and the machine on which the client will run both have 2 NICs. The IP addresses involved are:
Server NIC 1: 192.168.132.14 <-- This is the one I want to bind
Server NIC 2: 192.168.132.15
Client NIC 1: 192.168.132.16
Client NIC 2: 192.168.132.17
QUESTION 1:
In my server application, if I use INADDR_ANY when binding my listening socket, which of my two IP addresses will be used? Would I be correct to assume that there's no telling and that I should just use inet_addr("192.168.132.14") in place of INADDR_ANY?
QUESTION 2:
How can the client control which IP address he uses when connecting to me? Would he simply call bind() before calling connect()? Am I liable to see him as connecting from either address (no telling which one) if he does not?
When calling listen() on a server socket, binding to INADDR_ANY will bind the socket to all available local IPs on the machine. That allows a client to connect to any of the server's IPs. If the server uses inet_addr() instead, that will be the only IP that the server can accept client connections on.
When calling connect() on a client socket, it has to indicate a specific IP that the server is listening on. If the client wants to pick which local IP it binds to for its endpoint of the connection, it can call bind() on itself before calling connect(). If the client does not bind to a specific IP, or it binds to INADDR_ANY, the socket will use the first IP it finds that has an available route to the server IP being connected to.
Once the connection has been established, both parties can call getsockname() and getpeername() on their respective socket endpoints at any time to discover which IPs (and ports) are actually in use for that connection.
What I think of a port is: Whenever a message arrives to a machine, it is copied to a memory area which is mapped to the port specified and the concerned application or service is notified that a message has arrived for it.
If this is true, then what happens if two messages arrive for two different services listening on the same port ? ( either http or tcp )
And why can not two named pipe addresses use the same named pipe ?
TCP identifies "connections" via a tuple of { local ip, local port, remote ip, remote port }. Therefore, since each incoming connection has a different remote ip/port pair, your local machine can distinguish between them.
HTTP uses TCP for its transport. Thus, an HTTP port is a TCP port.
If you've ever had your machine get a new IP address while you had connections open, you'll note that they break the first time they send any data out since the remote host does not recognize the (new) address and sends a RST response.
A pipe has only its name to distinguish it so there is only one "connection" no matter how many writers it has.
Your description is one way to handle incoming messages.
In the case of two web sites listening on the same port, there is one web server listening on that port, which then looks at the http host header to find the correct web site to forward the request to.
The same is true for named pipes, the RPC listener listens on the TCP port, and then finds out that it is a named pipe message and then forwards the message to the right named pipe.
From what I understand, each HTTP request uses its own TCP connection (please correct me if i'm wrong). So, let's say that there are two current connections to the same server. For example, client side javascript code triggering a couple of AJAX POST requests using the XMLHttpRequest object, one right after the other, before getting the response to the first one. So we're talking about two connections to the same server, each waiting for a response in order to route it to each separate callback function.
Now here's the thing that I don't understand: The TCP packet includes source and destination ip and port, but won't both of these connections have the same src and dest ip addresses, and port 80? How can the packets be differentiated and routed to appropriately? Does it have anything to do with the packet sequence number which is different for each connection?
When your browser creates a new connection to the HTTP server, it uses a different source port.
For example, say your browser creates two connections to a server and that your IP address is 60.12.34.56. The first connection might originate from source port 60123 and the second from 60127. This is embedded in the TCP header of each packet sent to the server. When the server replies to each connection, it uses the appropriate port (e.g. 60123 or 60127) so that the packet makes it back to the right spot.
One of the best ways to learn about this is to download Wireshark and just observe traffic on your own network. It will show you this and much more.
Additionally, this gives insight into how Network Address Translation (NAT) works on a router. You can have many computers share the same IP address and the router will rewrite the request to use a different port so that two computers can simultaneously connect to places like AOL Instant Messenger.
They're differentiated by the source port.
The main reason for each HTTP request to not generate a separate TCP connection is called keepalives, incidentally.
A socket, in packet network communications, is considered to be the combination of 4 elements: server IP, server port, client IP, client port. The second one is usually fixed in a protocol, e.g. http usually listen in port 80, but the client port is a random number usually in the range 1024-65535. This is because the operating system could use those ports for known server protocols (e.g. 21 for FTP, 22 for SSH, etc.). The same network device can not use the same client port to open two different connections even to different servers and if two different clients use the same port, the server can tell them apart by their IP addresses. If a port is being used in a system either to listen for connection or to establish a connection, it can not be used for anything else. That's how the operating system can dispatch packets to the correct process once received by the network card.