I am working on a client/server program with one server (not behind NAT) and many clients that are using NAT. I need the server to be able to transfer files to the clients every so often, thus the server must be able to initiate TCP traffic when needed. I have already figured out how to do this with UDP by caching the clients' IPEndPoints and using them later.
Can anyone recommend some sample code or a project (with source) they have seen that can do this? There are lots of Chat or IM projects out there to learn from, but they generally use only UDP across NAT or only work on LANs without NAT being used. C++/C#/VB source with a solution would help a lot. Thanks.
Your best options:
Clients polls periodically to discover if new files are available. Simplest option. This may or may not scale depending on how many clients and how often they would need to poll.
All clients keep a persistent TCP connection to the server. Server sends files to a specific client when ready. Avoids the polling overhead of #1, but might have issues if the number of clients reaches into the thousands if you haven't designed your service to scale for the C10K problem.
Clients connect to a notification server which is designed to handle many clients simultaneously connected. Client sends its notification server parameters to file transfer service and disconnects. When file server has a new file available, server sends notification through notification service to tell client to connect back for an awaiting file. Client disconnects from file server after file transfer is done.
Related
I have a data vendor for real-time data that has a strict limit on the number of websocket connections I am allowed to make to their API. I have multiple microservices that need to consume this data, with some overlap in subscriptions. The clients do not need to communicate back anything beyond subscriptions.
I would like to design a system using a proxy-server that maintains a single websocket connection to the data vendor and then relays the appropriate messages to the clients via websocket. Optimally, the clients would be able to interact with the proxy server as if it were the data vendor's API.
I have looked at various (reverse?) proxy server solutions here, but have not found specific language about reducing the number of connections to the upstream data source. For example, I have looked into NGINX, but I can't tell if the proxy will combine client connections into a single upstream connection. The other solution I have researched is just putting all messages into a Kafka Pub/Sub via a connector, and have each client subscribe there.
I am curious if there are any existing, out of the box solutions to this problem before I implement my own solution.
I would like a bidirectional protocol working between two computer to send data between each other that will continuous to work when i change network (in java).
I tried to use websocket to send data between the two computer (not that the two computer are client and server the server is in amazon with a static ip address,while the client is in my local network) i this is the behaviour observed.
When i try to connect the client to the server the communication works and data are sent very well between each other.
But when i switch the client from one network to another network.
but when i switch my client from one network to another network (because the network lost internet connection),obviously the client has changed ip address, the communication between the computers (client are server) doesn't work any more. How can i do such that this communication still available?
If it isn't possible, is there any bidirectionnal protocol that still working when i switch the client from one network to another one?
I cannot think to another bidirectional protocol that automatically handles ip switch. I just can guarantee there is no "standard" protocol that does it.
It is something that you can handle at application level on top on WebSocket.
For example:
server side: you assign an univocal id to every client. You keep track of connected clients and stop tracking them when they are disconnected for too long time. If a client with a known id asks to start a websocket connection you can continue from where you left off, else you assign a new id;
client side: when the connection goes down (I suppose onerror event) you periodically try to start a new websocket handshake sending your id;
of course using a simple id is not so secure and it does not take into account if you reload the page or open it from another tab. Anyway those problem can be easily solved in lot of different ways (for example if the user are authenticated).
I want my client program to communicate with a server without making the user add an exception to Windows Firewall in elevated mode. Is there a way to do this? HTTP? For instance, uTorrent and Google Chrome can both be installed by a regular (non-admin) user, and both programs network quite extensively - how do they do this? Am I missing something about how the firewall and/or ports works?
Yes there is a way. Assuming that your client program is the one running on the users machine and that your client program is the one initiating communication with the server then your client program generally would not need to require end user to open any exceptions in the windows firewall as long as you stick to using http over port 80. Http on port 80 is generally open for outbound traffic (initiated by the client) and therefor you could build your communication (and if needed your own protocol) on top of the http protocol. This is the typical scenario for webserver and webbrowsers (clients).
If you need the server to initiate the communication it becomes more complex and a lot of different approaches could be used. Choice of communication channels and structure should depend on factors like whether you would want to communicate to one client at a time or many (broadcast/multicast), do you need encryption, what are your needs for speed (throughput and latency), what kind of system are you trying to build and so on.
Many webapplications achieve an effect of a server initiated communication by using special techniques called polling, long polls, comet, websockets and so on. these work through http on top of tcp/ip on port 80. Other systems employs subscription mechanisms to be able to get notified through a third part if something new has happened. If you need server initiated communications please let me now and i will try to give a better explanation on the options.
How does a web server handle multiple incoming requests at the same time on a single port(80)?
Example :
At the same time 300k users want to see an image from www.abcdef.com which is assigned IP 10.10.100.100 and port 80. So how can www.abcdef.com handle this incoming users' load?
Can one server (which is assigned with IP 10.10.100.100) handle this vast amount of incoming users? If not, then how can one IP address be assigned to more than one server to handle this load?
A port is just a magic number. It doesn't correspond to a piece of hardware. The server opens a socket that 'listens' at port 80 and 'accepts' new connections from that socket. Each new connection is represented by a new socket whose local port is also port 80, but whose remote IP:port is as per the client who connected. So they don't get mixed up. You therefore don't need multiple IP addresses or even multiple ports at the server end.
From tcpipguide
This identification of connections using both client and server sockets is what provides the flexibility in allowing multiple connections between devices that we take for granted on the Internet. For example, busy application server processes (such as Web servers) must be able to handle connections from more than one client, or the World Wide Web would be pretty much unusable. Since the connection is identified using the client's socket as well as the server's, this is no problem. At the same time that the Web server maintains the connection mentioned just above, it can easily have another connection to say, port 2,199 at IP address 219.31.0.44. This is represented by the connection identifier:
(41.199.222.3:80, 219.31.0.44:2199).
In fact, we can have multiple connections from the same client to the same server. Each client process will be assigned a different ephemeral port number, so even if they all try to access the same server process (such as the Web server process at 41.199.222.3:80), they will all have a different client socket and represent unique connections. This is what lets you make several simultaneous requests to the same Web site from your computer.
Again, TCP keeps track of each of these connections independently, so each connection is unaware of the others. TCP can handle hundreds or even thousands of simultaneous connections. The only limit is the capacity of the computer running TCP, and the bandwidth of the physical connections to it—the more connections running at once, the more each one has to share limited resources.
TCP Takes care of client identification
As a.m. said, TCP takes care of the client identification, and the server only sees a "socket" per client.
Say a server at 10.10.100.100 listens to port 80 for incoming TCP connections (HTTP is built over TCP). A client's browser (at 10.9.8.7) connects to the server using the client port 27143. The server sees: "the client 10.9.8.7:27143 wants to connect, do you accept?". The server app accepts, and is given a "handle" (a socket) to manage all communication with this client, and the handle will always send packets to 10.9.8.7:27143 with the proper TCP headers.
Packets are never simultaneous
Now, physically, there is generally only one (or two) connections linking the server to internet, so packets can only arrive in sequential order. The question becomes: what is the maximum throughput through the fiber, and how many responses can the server compute and send in return. Other than CPU time spent or memory bottlenecks while responding to requests, the server also has to keep some resources alive (at least 1 active socket per client) until the communication is over, and therefore consume RAM. Throughput is achieved via some optimizations (not mutually-exclusive): non-blocking sockets (to avoid pipelining/socket latencies), multi-threading (to use more CPU cores/threads).
Improving request throughput further: load balancing
And last, the server on the "front-side" of websites generally do not do all the work by themselves (especially the more complicated stuff, like database querying, calculations etc.), and defer tasks or even forward HTTP requests to distributed servers, while they keep on handling trivially (e.g. forwarding) as many requests per second as they can. Distribution of work over several servers is called load-balancing.
1) How does a web server handle multiple incoming requests at the same time on a single port(80)
==> a) one instance of the web service( example: spring boot micro service) runs/listens in the server machine at port 80.
b) This webservice(Spring boot app) needs a servlet container like mostly tomcat.
This container will have thread pool configured.
c) when ever request come from different users simultaneously, this container will
assign each thread from the pool for each of the incoming requests.
d) Since the server side web service code will have beans(in case java) mostly
singleton, each thread pert aining to each request will call the singleton API's
and if there is a need for Database access , then synchronization of these
threads is needed which is done through the #transactional annotation. This
annotation synchronizes the database operation.
2) Can one server (which is assigned with IP 10.10.100.100) handle this vast amount of incoming users?
If not, then how can one IP address be assigned to more than one server to handle this load?
==> This will taken care by loadbalancer along with routetable
answer is: virtual hosts, in HTTP Header is name of domain so the web server know which files run or send to client
I always get these two terms confused. How do you determine which side is the server and which side is the client? Is it determined by whether it's sending or receiving data? (Assuming the connection goes one-way)
Thank you,
In TCP, it's determined by the side that initiated the connection. The client initiates a connection, and the server listens for and accepts a connection. Once connected, data can flow both ways.
Definitions:
Server-side refers to operations that are performed by the server in a client–server relationship in computer networking. Typically, a server is a software program, such as a web server, that runs on a remote server, reachable from a user's local computer or workstation.
Client-side refers to operations that are performed by the client in a client–server relationship in a computer network. Typically, a client is a computer application, such as a web browser, that runs on a user's local computer or workstation and connects to a server as necessary.
If there are a lot more instances of one side of the connection than the other, the one with more instances is the client.
If one side stays running a lot longer than the other, the one that stays up longer is the server.