Ok so I've been trying to teach myself some socket programming. I wrote myself a little C# application with an async server and I understand most of it, except for the following:
So the server has a port it listens on for connections then when it receives a connection it creates a different socket to do the communication on. This it what I dont understand... How does the communication happen between the client and the server when in theory the client has no idea what port has been elected for this new connection?
Thanks for all your answers
Edit: As far as I understand the listening thread listens on the default port, but all messages are then handled on a different socket for each client?
Edit Again: Some how you guys are misunderstanding my question. I understand normal socket communication. My problem is with an async server where the listening socket is different from the connecting socket. Ie.
Server listens on default port
Client attrmpts to connect.
Server receiver request.
Server then creates a communication socket between client
and server and continues listening
on the default port.
My problem is at the last step. How does the client now know how to communicate on the new socket?
Here is some sample code
http://msdn.microsoft.com/en-us/library/5w7b7x5f.aspx
Although this question was posted over a year ago, I belive it is worth trying to clarify (or confuse?) it a bit more.
"How does the client now know how to communicate on the new socket?" - The client is not aware that a new socket was created. It simply keeps on sending data (packets) to the same port.
However, this gives rise to another question: How does the server know which data comes from which client? - Thanks to the TCP and IP protocols the server knows both the address of the client and the source port from which the packets were sent. With this information the server can receive packets from multiple clients and multiple (client) ports and route them to the correct socket. For this question, think of server sockets as filters: when packets are received from client X - port Y then route them to socket Z.
"...does it now know it needs to communicate on a different socket/port?" - This is a frequent source of confusion. When a new socket is created on the server to receive packets (after the connection has been established) it does not use a new port, it keeps on using the original port number. The entire socket creation process on the server side is transparent to the client. The client never knows (nor does it need to know) that a new socket was created to handle its packets.
Google TCP header for more information.
Hope this helps someone.
When the client connects to the server, it selects the port to connect to. The client also includes a port that it will receive responses on. This is typically a randomly selected port, but it's possible for the client to override that.
Think of it like a phone call. When you call someone, there is the phone number you call, and you also have a phone number. even though you both talk to each other, both phone numbers are in use.
That's not a perfect analogy, since phone numbers are more like IP addresses and trunk lines need not have an originating phone number in all cases, but the same concept applies.
Simply put, the TCP protocol requires an originating port and destination port as well as originating ip address and destination IP. When packets are sent in either direction, the apropriate IP/Port is used either way.
Actually the new connection use the same port. A server listen on a specific port for incoming connection, anytime it receives connection request from client, the server accept it and create a new thread to process the request. And then continue to listen on that port.
Definitions
Client: The socket at the remote machine that is connecting to the server
Server: The socket that is waiting for connections on the server
ServerClient: The socket which is communicating with the Client
Answer
I couldn't find any details about how the ServerClient port is transfered to the Client after the Server has accepted it. But it's most likely transfered in the handshake. Feel free to read RFC793 if you want to know more.
I wont go through the details, but you can read about passive connects to get more information about how listener sockets work at lower levels. But basically the purpose of listener sockets (Server) is only to accept sockets (ServerClient).
The port that the ServerClient uses is assigned by the socket implementation in the operating system and is nothing that you can control. All you need to know is that the each connected ServerClient will get it's own port and it's transfered to the Client during the (threeway) handskake (I think ;))
Related
This is my first foray into socket programming. I need some help to get started. Basically, I have a server that sends out status updates on a specific TCP port. I need a client computer to look out for those update messages. I've decided to create a Windows Service in C# that will be installed on the client computer. I can't figure out if the service should be TCP listener (server) or client. Any guidance will be highly appreciated.
Since you already have a server that will send the updates, all you need to do to receive these updates is to create a TCP client on your host. This will serve as the listener, just connect it to the appropriate server's IP and port. Alternatively if you already have a client that connects to the server and just want to intercept the traffic, use something like tcpdump.
Figured it out. This comment from TcpClient Class threw me off:
// Note, for this client to work you need to have a TcpServer
// connected to the same address as specified by the server, port
// combination.
I'm working on a game that depends on the standard System.Net.Sockets library for networking. What's the most efficient and standardized "system" I should use? Should the client send data requests every set amount of seconds, when a certain event happens? My other question, is a port forward required for a client to listen and receive data? How is this done, is there another socket created specifically for listening only on the client? How can I send messages and listen on the same socket on the client? I'm having a difficult time grasping the concept of networking, I started messing with it two days ago.
Should the client send data requests every set amount of seconds, when a certain event happens?
No. Send your message as soon as you can. The socket stack has algorithms that determine when data is actually sent. For instance the Nagle algorithm.
However, if you send a LOT of messages it can be beneficial to enqueue everything in the same socket method call. However, you need to send several thousand of messages per client and second for that to give you any benefit.
My other question, is a port forward required for a client to listen and receive data?
No. Once a socket connection have been established it's bidirectional. i.e. both end points and send and receive information without screwing something up for the other end point.
But to achieve that you typically have to use asynchronous operations so that you can keep receiving all the time.
How is this done, is there another socket created specifically for listening only on the client?
The server has a dedicated socket (a listener) which only purpose is to accept client sockets. When the listener have accepted a new connection from a remote end point you get a new socket object which represents the connection to the newly connected endpoint.
How can I send messages and listen on the same socket on the client?
The easiest way is to use asynchronous receives and blocking sends.
If you do not want to take care of everything by yourself, you can try my Apache licensed library http://sharpmessaging.net.
Creating a stable, high quality server will require you to have a wealth of knowledge on networking and managing your objects.
I highly recommend you start with something smaller before attempting to create your own server from scratch, or at the very least play around with a server for a different game that's already made, attempt to improve upon it or add new features.
That being said, there are a few ways you can setup the server, if you plan on having more than a couple of clients you don't generally want them to all send data whenever they feel like it as this can bog down the server, you want to structure it in such a way that the client sends as little data as possible on a scheduled basis and the server can request more when its ready. How that's setup and structured is up to you.
A server generally has to have a port forwarded on the router in order for requests to make it to the server from the internet, and here is why. When your computer makes a connection to a website (stackoverflow for example) it sends out a request on a random port, the router remembers the port that you sent out on and remembers who sent it (you), when the server sends the information you requested back the router knows you wanted that data and sends it back to you, in the case of RUNNING a server there is no outbound request to a client (Jack for example), so the router doesnt know where jacks request is supposed to go. By adding a port forwarding rule in the router your saying that all information passed to port 25565 (for example) is supposed to go to your server.
Clients generally do not need to forward ports because they are only making outbound requests and receiving data.
Server Starts, server starts listening on port 25565
Client starts, client connects to server on port 25565 and initiates a connection
Server responds to client on whatever port the client used to connect (this is done behind the scenes in sockets)
Communication continues from here.
Kind hard to explain so here it is step by step:
Client sends data to Server via Udp. Client port X to server port 3000.
Server uses this communication to set up a UdpClient to listen for this specific client on port 3001 for client port X.
Client then sends data as needed on local port X to server port 3001.
Everyone is happy.
My question is: Can I assume that if the client is communicating to the server behind a NAT and it punches a udp port, that if it communicates to ANOTHER port on the same server that it will use the same port?
[Edit: formatting]
No you can not assume that. It may happen or it may not happen, it is up to the writers of the software of the NAT firewall the client is punching through.
A complex software may detect that you are talking to the same server but a different port and reuse the outbound port, but simpler software (the kind you would frequently see on home routers) may be "dumber" and just use a new randomized port per connection.
I'm currently trying to make an online video game, which currently uses TCP to send packets. I want to use UDP, but I'm extremely new to UDP and I'm having some issues.
When I test my server/client(s) on the same computer (localhost), the packets seem to be interfering with each other.
For example, if the client sends a packet to the server (UDP, 127.0.0.1:1338), the client ends up receiving the packet, since the client is also listening for packets from 127.0.0.1 on port 1338. Similarly, when I try to test 2 clients and 1 server, the clients may send out packets which are meant for the server, but are picked up by the other client.
How can I test UDP on localhost since all packets are being received from/sent to 127.0.0.1:1338? Do I need to implement some sort of layer in my packets that distinguishes if the packet is meant for the server, or a specific client?
Only your Server should listen on the defined port number (1338). Each client should select a free port number and send the server this port number. The server has to store the client information and send then the packets to the clients in this client list.
The clients should also send a goodby packet when the client is closing to know on the server side which clients are still available and which aren't participating anymore.
You should also implement some kind of housekeeping in this client list. For example store the timestamp of the last received packet from the client and remove clients that haven't sent data for some time (crashed client, lost connection ...) from the list.
An additional layer will not help - because the server may never actually get the packet.
Make the ports on the server and client configurable. That way you could have different ports on the same machine for testing and change it when going to production. Just remember you need to configure both ports in both the client and server. This is a good practice anyway.
You still have another problem - of several clients residing on the same machine and listening to the same port. You can have a random port for each client (the client selects one in random and then notifies the server). Or you can try binding to different IP addresses (one will use 127.0.0.1 an another will use the real IP of the PC), but it's not extensible.
If you are going to use this in a LAN setup, then you can always filter the received packet based on the sender's address -- recvmsg() of UDP allows you to retrieve sender's address and port number. If you are going to use this in a WAN setup, then this likely would not be an issue unless you are trying to do multicast. And, even with multicast, duplciate packets are not send back to the receiver. You can use IP_MULTICAST_LOOP to disable this option.
Will a listening Tcp Socket create a new socket for each established connection to handle incomming data from a specific client? This answer: https://stackoverflow.com/a/26374740/5342935 suggest the following:
the server's original socket is never used for actually communicating over a connection. It's simply the socket that's used to create connections.
However: I built a basic Tcp/Ip application and looked at the packets via wireshark, and found out that the data that is sent from the client to the server is sent to the same ip:port (= same socket, according to this: https://stackoverflow.com/a/152863/5342935 (suggests that a Socket is just one endpoint of a connection.)) as the connection request. Due to the upvotes to the first answer link above, I first thought it may be simply wrong, however multiple people confirmed it being right, which confuses me.
Your observation is correct but conclusion is wrong :-)
The listening socket is really used to just establish the connection. The data transfer connection then uses the same pair of client and server port but operating system distributes the data to different socket channels specific to client it belongs to.