The simple way to support multiple clients is to fork a process for each incoming connection and handle the client through that process and the other process then listens on the default port.
However I have heard that not only is the process forked, but the connection itself is redirected from the default port at which the server is listening to a different port on the server side. This improves performance. I am unable to find any reliable reference to this topic. Is this a standard procedure
This is not the case for most protocols on the internet. For example, public web servers will always listen on port 80 for every request. FTP servers on port 21 and so on. Where did you get your information? With more information on the context, someone might be able to help establish the circumstances you're talking about. What's your source?
Related
I have put together an architecture that at high level is best described below
Five node docker swarm cluster
Have say 5 instances of my dockerized micro service running one copy on each of the swarm nodes
The service offers functionality via REST end points
One such functionality is downloads and they work perfectly, I wrote some code in Scala/Play framerwork, dockerized the service and deployed it.
I also know that since I use swarm , it internally does LB per request for me.
I have some questions on WebSocket and how load balancer does not ruin things during download.
I start a 5GB file download and it works. I am using HTTP stream or chunked I guess it does not matter. Now my question is once my REST end point for download is hit, the TCP connection remains open and since it is open until the server closes the connection, it is due to this that the swarm load balancing does not interfere? In short, each time a client requests a HTTP call, swarm load balances it but once the TCP socket is established as in case of specific download example, the request is served by one node as the connection is not re-stablished during the download process?
If a client opens a web socket, it will hit one of the nodes of swarm where the service is running and the websocket connection since it is open, the same service instance will push the notifications?
If for some reason the websocket dies, a new connection might be established by client but the request might end up on some other service instance and will remain like that until a new connection is again established?
Are above 3 points correct in my understanding? Is there some reading material/blogs I can find more on elaborating this?
Maybe using nginx like proxy LB, ip_hash mode
Specifies that a group should use a load balancing method where requests are distributed between servers based on client IP addresses. The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable. In the latter case client requests will be passed to another server. Most probably, it will always be the same server as well.
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash
Short version: How would you recommend going about connecting a client to a server that are on the same local network, without manually entering the ip, when broadcast is disabled?
Further details: I am working on an educational multiplayer game for children. Many schools appear to be blocking broadcasting for security reasons. The children will be rather young, so it could be difficult for them and error-prone to have to enter the IP manually. They will all be in the same room and will all see the server screen. The game is made in Unity (C#).
Potential solutions: Here's what I thought about:
Connecting both the local server and clients to an external server, communicating the local server ip through the clients through the external server, then connecting directly and disconnect from the server. Not ideal because of the extra hosting costs.
Send a regular UDP message periodically to all ips on the subnet? This will probably be picked up by any decent firewall and blocked though, right?
Putting a QR code on the server that kids would take a picture of with the client app and have it connect that way? May be more of a hassle.
Having the server play random tones corresponding to numbers that the client is listening for? (Speakers may not always work though)
Sounds like the first one is the most sane and easy solution. Do you have any other ideas on what someone in this situation could try?
Is UDP multicast possible?
If yes then a common solution is that all participants join the same multicast group and the server listens on a well known port. If a client wants to know the address of the server it sends a packet to the multicast group, which is received by the client and answered with another packet, which then can be used by the client to determine the servers address.
In addition to that servers can also announce their presence in regular intervals by sending a suitable message to the multicast group.
What I can think of is an ad-hoc communication protocol between all the devices. Say you have 1 server and 10 clients. All the devices should run a service(say server-discovery) that binds to a fixed port say 9999. Now any time the client wants to connect to the server and doesn't know the IP, it starts a scan. Loops through different IPs and tries to connect to 9999. If it manages to hit, it asks for the server IP. In case it manages to hit the server it will get the IP since the server knows it's own IP and the client will maintain the server IP in a cache. If the client hits another client. It can ask for the server IP. It the other client knows the IP it will share the info else decline.
I agree there is a lot of overhead, but I think this will be robust unlike sound and would reduce cost of printing QRs everytime.
on the local network the traffic is direct from host to host.
I don't understand which devices is blocking local broadcasts.
if there aren't too many peers on the LAN ( less then 100 ), I think udp broadcasts work fine and you dont pollute the network.
to have an idea of your "pond", I suggest you to sniff your local traffic.
there are many broadcasts : arp, windows, ipp, dropbox...
I am attempting to establish a connection between two computers using MSDN codes:
Client code:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737591(v=vs.85).aspx
Server code:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737593(v=vs.85).aspx
These codes run perfectly on a local network, but my intention is to establish a connection over the internet, where both computers are behind routers. I know port-forwarding is a viable solution. But I just don't know how.
For example, does even the client need port-forwarding, not just the server?
Further more, I am unable to properly configure my router to port-forward. Its model is Level One WBR-3407a. I tried this guide:
http://portforward.com/english/routers/port_forwarding/LevelOne/WBR-3407a/defaultguide.htm
But it didn't work. As you may note, this guide doesn't anywhere in it specify what port to use? is it possible to port-forward without specifying which port to forward?!
You need to configure port forwarding on the router to which the "server" is connected, and yes, you do need to specify a port (there's an exception, but let's not worry about it now). You typically wouldn't need port forwarding on the router to which the client computer connects.
Looking at the MSDN code you linked, you need to port forward port 27015, so on the router for your server, you want to add port forwarding entries for incoming TCP connections on port 27015 and to forward them to the IP address of the computer running the server, also on port 27015.
For future reference, this question is more appropriate for SuperUser or, less likely, for ServerFault.
I'm building a chat server with .NET. I have tried opening about 2000 client connections and my Linksys WRT54GL router (with tomato firmware) drops dead each time. The same thing happens when I have several connections open on my Azureus bit-torrent client.
I have three questions:
Is there a limit on the number of open sockets I can have in Windows Server 2003?
Is the Linksys router the problem? If so is there better hardware recommended?
Is there a way to possibly share sockets so that I can handle more open client connections with fewer resources?
AS I've mentioned before, Raymond Chen has good advice on this sort of question: If you have to ask about OS limits, you're probably doing something wrong. The IP protocol only allows for a maximum of 65535 ports and many of these are reserved and not available for general use. I would suggest that your messaging protocols need to be thought out in more detail so that OS limits are not an issue. I'm sure there are many good resources describing such systems, and there are certainly people here that would have good ideas about it.
EDIT: I'm going to put some thoughts about implementing a scalable chat server.
First off, designate a single port on the server for clients to communicate through. Whenever a client needs to update the chat state (a new user message for example) do the following:
create message packet
open port to server
send packet
close port
The server then does the following:
connection request received
get packet
close connection
process packet
for each client that requires updating
open connection to clients
send update packet
close connection
When a new chat session is started, the client starting the session sends a 'new session' message to the server with the clients user details and IP address for responses. The server creates a new chat session and responds with the session ID. The client then sends packets containing the messages the user types, the server processes them and forwards the message to other clients in the same session. When a client leaves the chat, it sends a 'end session' message to the server. The server removes the client from the session and destroys the session when there are no more clients in the session.
Hope that gets you thinking.
i have found some answers to this that i feel i should share:
Windows 2003 server has a limit on the number of ports that may be used. but this is configurable via a registry tweak to change the MaxUSerPort setting from 5000 to say, 64k( max).
Exploring further, i realize that the 64k port restriction is actually per IP address, hence a single server can easily attain much more ports, and hence TCP connections by either installing multiple network cards, or binding more than one IP address to a network card. that way, you can scale your system to handle n x 64k ports.
Had for days a problem with the available sockets on my Window 7 machine. After reading some articles about socket leaks in Win 7, I applied a Windows patch - nothing changed.
Below there is an article describing windows connection problems in great detail:
http://technet.microsoft.com/en-us/magazine/2007.12.network.aspx
For me it worked the following:
Open Regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters: Create TcpNumConnections, REG_DWORD, decimal value 500 (this can be set according to your needs); EnableConnectionRateLimiting, REG_DWORD, value 0;
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip: Create MaxUserPort, REG_DWORD, decimal value 65534
Restart Windows
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?