i am wondering how tcp servers work because there is no multicasting. I am interested in using tcp for my game since it won't require to much packets to be sent like some other games. It still needs to have a client / server architecture though.
Since there is no multicasting, is there just a loop to send everything directly from server to client for every client? Is this what minecraft does (cuz i read it uses tcp)
it was my understanding that only 1 socket can be bound to a port. With udp, the server socket can accept connections from IPAdress.Any, so it can receive information from all clients. Since TCP is connection only, how would this work? Can multiple TCP connections be made on the same socket?
Only one listening connection can exist per port on the server. However, many clients can connect to that one listening port. A "Connection" under the hood is the combination of ServerIP + ServerPort + ClientIP + ClientPort, also the client port does not need to be the same every time (only the server side port needs to stay static), the OS chooses a random high number port and give that to the client side for the connection. That is why you can have many outgoing connections on a client but only one listening connection on the server.
Look at this page for a example on how to set up multiple connections to one port.
Related
I've an application in c# windows forms through which I stream photo taken by a web cam in few seconds interval. The photo data get sent to a server listening on TCP port.
My question is if this application is installed on hundreds of computers, shall there be an issue to listen on one single port or should I assign a different port to each client? Keeping in mind that photos get sent after every few seconds.
Here is my code of server listener.
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
socket.Bind(new IPEndPoint(IPAddress.Parse("some ip"),5001));
Task.Factory.StartNew(() =>
{
socket.Listen(500);
//socket listening code.
}, TaskCreationOptions.LongRunning);
Thanks.
TCP Connections are characterised by four parameters - source IP Address and Port and destination IP Address and Port. Provided those four are unique, no confusion ensues.
Given that source's are either machines actually assigned unique addresses (more likely with IPv6) or are tunnelling through NAT devices (and thus asigned unique source ports), there's no need to do anything on the server side.
If you're thinking of assigning anything to each connected client (beyond the socket and some buffers), you're probably doing something wrong. Don't dedicate any exclusive resources to the clients.
See: the C10k problem.
Note that when you use a listener port, behind the scenes you end up using an ephemeral port for the established connection after the listener has handed it over - but from the connecting client's perspective, that doesn't matter - the listener port remains a single point of entry for all the eventual sockets.
FWIW: the web-sockets server that drives the real-time updates here on Stack Overflow currently averages 14,500 sockets per port, 3 ports per service instance, 9 service instances, for a total of about 392,000 sockets. We've seen it much higher at some points in the past. So yes, you can easily support a few hundred clients o a single listener port, but: it gets non-trivial the more sockets you want to support, and you absolutely shouldn't use theads per client if you're going over a very small number of clients.
Don't worry you can listen multiple sockets on a same port, so multiple clients can communicate on the same port.
For example, you probably know that when you access on a website, you're connecting to a server on the port 80 (or 443 for https), well... Fortunatly, a website can be accessed by multiple clients, and all on the same port ! ;)
is it possible to have one socket router that would pass incoming sockets to socket servers?
I need this because I want to have multiple servers for handling sockets but only one port for clients to connect to. so if one of the servers goes down, router would send the socket to other healthy socket servers.
Is this even possible and how? or any other solution for my problem?
Yes this is definitely possible, and is used very widespread.
Basically you need to have one TCP server running on that one port you want clients to connect to. Then you can listen for connections. When a connection is established you can reroute packets to other servers (you choose).
Listen on a port with your main server
Accept connections as they come in.
When a connection is opened, read the data in another thread. Take that data and send it to the other server you want to.
Basically, it is a proxy.
I am designing a server client app in C#.
the client connect and communicate with the sever threw tcp socket.
in the server side I am using the socket.accept() method in order to handle new connection from client. when client is connecting, the server use a random port in order to communicate with the client.
so my question is.. how many clients the server can receive in this kind of form?
is there another form that I should use in order to handle lots of clients?
This is practically limited by the OS. You have to test this. On Windows you must use fully asynchronous socket IO at this scale. You will probably be limited by memory usage.
On a TCP level there is no practical limit. There can be one connection for each combination of (server port, server ip, client port, client ip). So with one server port and one server ip you can serve an unlimited amount of clients as long as they have less than 65k connections per client.
You do not need to pick a random port on the server. This is a common misconception.
in the server side i am using the socket.accept() method in order to handle new connection from client. when client is connecting, the server use a random port in order to communicate with the client.
Not unless you open another, pointless, connection from server to client, and you won't be doing that for firewall reasons. The accepted socket uses the same local port number as the listening socket. Contrary to several answers and comments here.
Your question is therefore founded on a misconception. Whatever you run out of, and it could be memory, thread handles, socket handles, socket buffer space, CPUs, CPU power, virtual memory, disk space, ..., it won't be TCP ports.
EDIT Adherents of the new-random-port theory need to explain the following netstat output:
TCP 127.0.0.4:8009 0.0.0.0:0 LISTENING
TCP 127.0.0.4:8009 127.0.0.1:53777 ESTABLISHED
TCP 127.0.0.4:8009 127.0.0.1:53793 ESTABLISHED
TCP 127.0.0.4:8009 127.0.0.1:53794 ESTABLISHED
TCP 127.0.0.4:8009 127.0.0.1:53795 ESTABLISHED
TCP 127.0.0.4:8009 127.0.0.1:53796 ESTABLISHED
TCP 127.0.0.4:8009 127.0.0.1:53798 ESTABLISHED
TCP 127.0.0.4:8009 127.0.0.1:53935 ESTABLISHED
and show where in RFC 793 it says anything about allocating a new port to an accepted socket, and where in the TCP connect-handshake exchange the new port number is conveyed.
You may like to see this question I asked in similar vein: https://softwareengineering.stackexchange.com/questions/234672/is-there-are-problem-holding-large-numbers-of-open-socket-connections-for-length, and particularly some of the comments.
The answer seems to be that there is no practical limit. The combination of receive port and send port must be unique, and each of them can have 64K values. The total number of combinations is extremely large. There really are servers out there with extremely large numbers of open connections, but to get there you have to solve a number of other interesting problems. The question above contains a link to an article about a million connection server. See also How to retain one million simultaneous TCP connections?. And do a web search for the C10K problem.
What you probably cannot do is use synchronous ports and threads because you run into thread limits, not port limits. You have to use asynchronous ports and a thread pool. And you will have to write one to throw away, just to find out how to do it.
I have a custom TCP Server listening on port 5888(dummy port). The proxy server listens for incoming connections. When the proxy receives HTTP request for certain pages, it should relay it to the main server on port 80.For other page requests the proxy is required to send data to the main Server on port 8081.
The port 80 is used to service the HTML Pages where as the port 8081 is used for streaming data to the clients.
I am able to receive the incoming connections on the proxy and then read the data from the clients. After reading the data, I can determine which port to connect to on the main server for sending the data.
I am stuck at deciding how to connect on 2 ports for sending the data from the clients to the Main Server?
In that case you either need 2 socket connection objects to the same IP on the different ports (this is legal), or you have one connection object which reconnects according to the port you have to deal with.
Depending on how often you have to switch connections the latter version might have a huge overhead, plus the first one allows you to send data to both ports virtually simultaneously.
You need to stop thinking of your program as a server. After you have received the connection, read the data, and decided what port to send it to, shift gears and start operating as a client would.
Just open a new connection to "localhost" on either port 80 or 8081 and re-send the data you received as if you were the original client.
Your client is connected to the proxy server on port 5888 so no matter from what real server (Web or streaming) you take the data, you are going to provide the data to the client using port 5888 only.
It seems to be a not so practical solution. I am assuming here that you are trying to achieve a kind of control port and data port structure where one port is controlling the streaming from another port.
Just creating two sockets is sufficient for obtaining data from two servers. Here you will have to manually create a protocol which your client understands as you are going to provide both html and streaming data to the client using single port.
I am attempting to create a server and client that utilizes both TCP and UDP. The server works very well in a LAN setting but the UDP messages are not being received when transmitted over a WAN. I believe it is because the UDP socket used to send the data is not remaining in the NAT tables long enough to return any information. Is there a way to either make the UDP port stay open in the router (without port forwarding) or use the same port for UDP as the already connected TCP connection? Thanks in advance.
If you're not getting any traffic it is probably simply blocked by the firewall. In this case it is not about forwarding, it is about opening the port.
Most (if not all) NAT/Firewall devices will allow UDP traffic in both directions once a hole is punched through the NAT. That is, if my laptop here, sitting behind a NAT/firewall, sends a UDP packet out to the Internet my NAT/firewall will allow return UDP traffic to the originating port number through. I work a lot with UDP and my experience is that this is the rule and very few exceptions.
Keep in mind though UDP packets are not guaranteed to be delivered.
Is your client behind a NAT? Do any packets the client send get to the server? Is the problem in the server to client direction?
If you use the same port number for UDP and TCP this will not change the situation. You can't piggyback on a TCP connection because it is a different protocol.
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
http://en.wikipedia.org/wiki/UDP_hole_punching