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.
Related
I have created my own websocket class that extends the abstract System.Net.WebSockets.WebSocket Class. my class uses TcpListener and TcpClient to communicate. After this server receives an HTTP-Get-formatted request that asks to upgrade to a websocket connection, I am able to complete the handshake successfully and communicate with a websocket client.
Separately I have a simple HTTP server that sends and receives HTTP requests using HttpListener and HTTPClient.
Now I want to combine them.
I would like this HTTP server to, upon receiving a websocket request, transfer the "connection" to my websocket server to handle. However I am struggling to conceptually understand what a TCP "connection" is.
I know that I can create a TCPClient using an existing socket, but I am unsure how to retrieve the existing HTTPListener's socket (maybe it can't be exposed?). And for that matter I am unsure what would happen if I tried to have a TCPClient and HTTPListener sharing the same socket.
So how do I construct a TCPListener from an existing HTTPListener?
However I am struggling to conceptually understand what a TCP
"connection" is.
RFC 793, Transmission Control Protocol (and the subsequent RFCs that update it) is the standard for TCP. It explains what a TCP connection is, and later goes into more detail:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network and
host addresses from the internet communication layer, this forms a
socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed through
the known addresses. Establishing and learning the port addresses of
other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including
sockets, sequence numbers, and window sizes, is called a
connection. Each connection is uniquely specified by a pair of
sockets identifying its two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
I'm looking to enhance a WPF app I have that currently receives/broadcasts UDP datagrams within its network with a bridge functionality to share packets with other instances of the app on different subnets.
I essentially want one instance to connect with another and then be broadcast UDP packets while a connection is maintained. To do this, I figure a TCP connection will work at least for the handshake and periodic acks. However, I do not require the TCP overhead for the data itself, which could be transmitted multiple times per second for hours or longer (however long the two are connected).
Given these requirements does it make sense to do a hybrid where the TCP is used for handshaking/acks but data is sent via UDP (I assume the TCP connection can be configured to be kept open indefinitely), or would the additional overhead of sending the datagrams as TCP payloads be negligible? Or should I implement a syn/ack functionality within the UDP transmission? Is there an established standard for this sort of connection?
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 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.