I am trying to design a client server model for chat application.Do I need to have two different socket with different port to send and recieve.Actually I have 3 nodes.1 server and 2 client(or slaves).Message passed by client 1 for client 2 will always routed via server.What kind of port and number of socket i should use.Please exaplain I doing all these things in C++ using winsock and pthread API's.
Typically you use TCP (SOCK_STREAM). You need just one socket to for incoming connections. bind(2) it to a specific port. You can accept(2) any number of connections on it.
Several threads can wait (accept(2)) on the same socket. The OS will dispatch one connection to just one thread ;)
For each outgoing connection you have to create a new socket but you don't have to bind it. The OS will choose an appropriate IP/port itself.
Related
I read the docs, concerning the .listen() method, used in express. I can USE the method and setup a server that is listening to HTTP requests.
However, since I am fairly new to coding, I find it difficult to grasp whats really happening when using the .listen() method. The high level explanation "listening for connections" didn't help me.
I think, this could be made easier if I could actually see the function instead of only calling it.
Any help is very much appreciated
In a nutshell, the Express app.listen() method creates an http server object and then configures it to receive incoming TCP connections on a specific port and IP address so that when clients request a connection to that port and send an http request, the server can receive that http request and process it, sending a response. The code in app.listen() is shown below later in the answer - though all it does is call down to one further layer down in the http server object.
Here are the lower level details for how that works.
When a server wishes to start listening for incoming connections, it informs the local TCP stack by creating a socket and binding to a particular port and IP address. That essentially reserves that incoming port for this particular server (no other server will be allowed to also bind to that port). So, for example, on a regular http server on the default port, you would bind to port 80. This type of bound socket is used for incoming connections only, not for two-way communications with a client.
Then, the server informs the TCP stack that it is ready for incoming connections. At the TCP level, this is referred to as listen. Within nodejs, the bind and listen steps are combined into the one step called listen.
From then on, whenever the local TCP stack receives an incoming connecting request whose destination is the IP address and port that the server bound to, then that incoming connection will be accepted and inserted into a queue for the server that is configured for that IP address and port. There will typically be a maximum number of incoming connections that can be queued in this way and, if that number is exceeded, then the connection will be refused. This manages load and protects the host if the server gets "backed up" and is behind on processing incoming connections.
The server will then be informed by the TCP stack for each new incoming connection. Once the server accepts that connection, then it can start reading any data that the client has sent over the socket. In the case of an HTTP server working with the HTTP protocol, this would be the initial request protocol, method, version, headers and any body data. For different types of servers, the data would be in a different format.
Here's a useful diagram of the server:
Source: https://medium.com/javarevisited/fundamentals-of-socket-programming-in-java-bc9acc30eaf4
The server creates a socket used for the server to accept new connections..
It binds that socket to a specific IP address and port so it will only be informed about incoming connections targeted to that IP address and port.
It listens on that port to inform the TCP stack it is ready to accept incoming connections.
When it is notified of an incoming connection, it accepts that incoming connection.
Then it can read and write to that new connection over the new socket.
Then, sometime later, the incoming socket is closed to complete the client transaction.
The app.listen() method in Express encapsulates these steps and a few others. Internally (within Express), the code looks like this:
app.listen = function listen() {
var server = http.createServer(this);
return server.listen.apply(server, arguments);
};
You can see that method here in the open source repository.
To get an http server ready for steps 1-6 above, this creates the http server object within nodejs and then registers the app as the request listener for that server object (so it will be notified of incoming http requests).
Then, the call to server.listen() encapsulates steps 1-3 above.
Step 4 happens inside the http server object implementation and the app object is called when a new connection has been established and a new HTTP request is available. The http server reads the initial request and parses the http protocol and that initial request is already made available to the app for routing to the appropriate handler.
Then, subsequent calls such as res.send() or res.json() write a response back on the http socket and close the socket or res.end() will close it directly (steps 5 and 6 above).
Some other useful references:
Why is bind() used in TCP? Why is it used only on server side and not in client side? - Helps explain how a port and IP address define the TCP endpoint represented by a server. This port has to be known by the client so it can specifically request to connect to that port. The client end of the socket also has an IP address and a port, but its port can be dynamically assigned, thus the client does not have to bind to a specific port itself. The four pieces of data [server IP, server port, client IP, client port] define a specific TCP connection.
How TCP sockets work - has a good section about how new connections to a server work.
Understanding socket and port in TCP - talks about active and passive sockets. Passive sockets are sockets in "listen" mode used to accept incoming connections. Active sockets are two-way communications channels between two TCP endpoints.
Transmission Control Protocol (TCP) - more details on the various aspects of TCP from initiating a listening server, initiating a client connection to that server, through packet transmission to closing the socket.
There are a gazillion other references on the topic on the web. You can probably find 1000 articles on any single aspect of TCP that you might want more info about.
I think, this could be made easier if I could actually see the function instead of only calling it.
The underlying code for listen is inside the operating system's TCP stack and is not part of nodejs or Express. Express relies on the nodejs http server object as its interface to that and the nodejs http server object uses native code (built into nodejs) to call libuv (which is a cross platform C library that nodejs uses for networking and other things). Then, libuv talks to the underlying operating system APIs to reach the actual TCP stack on that target host. All of this is to put the server socket into listen mode so it can be notified of new incoming client connections to that target IP address and port.
Here's some doc on the related portions of the Linux TCP API if you want to see what the underlying TCP interface and description of that interface is:
socket() - https://linux.die.net/man/7/socket
bind() - https://linux.die.net/man/2/bind
listen() - https://linux.die.net/man/2/listen
And, portions of the libuv library that nodejs uses for networking:
TCP handles - http://docs.libuv.org/en/v1.x/tcp.html
Server listen() and accept() - http://docs.libuv.org/en/v1.x/stream.html#c.uv_listen
I have a tcp server running. A client connects to the server and send packet periodically. For TCP server, this incoming connections turns to be CONNECTED, and the server socket still listens for other connections.
Say this client suddenly get powered off, no FIN sent to server. When it powers up again, it still use the same port to connect, but server doesn't reply to SYNC request. It just ignores incoming request, since there exists a connection with this port.
How to let server close the old connection and accept new one?
My tcp server runs on Ubuntu 14.04, it's a Java program using ServerSocket.
That's not correct, a server can accept multiple connections and will accept a new connection from a rebooted client as long as it's connecting from a different port (and that's usually the case). If your program is not accepting it it's because you haven't called accept() a second time. This probably means that your application is only handling one blocking operation per time (for example, it might be stuck in a read() operation on the connected socket). The solution for this is to simultaneously read from the connected sockets and accept new connections. This might be done using an I/O multiplexer, like select(), or multiple threads.
I'm having difficulty finding a robust socket library for doing local tcp socket connections in node.js.
I'm a big fan of using libraries like SockJS or Socket.io for client/server socket connections but I know those use websockets which are different from regular sockets.
I'm wondering if I could use a Websocket library for local connections with similar performance as just using regular sockets or would that include lots of undesired networking overhead?
Basically I want to achieve these three things with sockets and I don't think the native networking module can do them out of the box.
Monitor the health of each socket in it's pool (Alive or dead).
Attach an id to each socket so you know where data is coming from
Build the data from the chunks sent through the sockets
WebSockets are a TCP-like connection, but which actually runs on top of an established HTTP(s) connection (which itself runs within a TCP-connection). This means:
There is additional overhead: all data gets put into special frames, also you have the HTTP connection establishment additionally to the normal TCP connection establishment.
They are not compatible with normal sockets, e.g. you need a WebSockets-aware peer on the other side of the connection.
Apart from that they add no additional reliability or features to the underlying TCP connection. E.g. your requirements are already possible with normal sockets.
How web servers serve multiply requests simultaneously. I think that sockets are used during the communication betwen client and server. But what if two clients try to connect one socket at one time? This socket will be used and second client could not be connected?
Servers can accept and service multiple client connections at the same time, usually by using multiple threads, overlapped/asynchronous I/O, or even forking multiple processes. But in any case, multiple clients are serviced in parallel to each other. A new client connection is refused only if the server has run out of resources to accept more clients.
We are developing a network application based on C/S, in this application the server needs to transfer files to clients and sometimes receive files from clients. So in the server application, for every client it needs to create a control socket and many transfer sockets.
My question is how we can create and define a socket as role of control socket or transfer socket? ( below are deleted: And how can the server application distinguish between the control socket and the transfer sockets? ). Currently the servers use a listening socket, and for all new connections established by accept(listening socket), it stores them equally in an array, finally lets the client register them to the server as control sockets or transfer sockets(means before transferring a file, the client needs to tell which socket it wants to use as control socket and which sockets it want to use as transfer sockets).
I don't think this is a good patter for creating control sockets and transfer sockets between server application and the clients. So is there any other patters that is suitable for this kind of problems?
how we can create this control socket and all the other transfer sockets?
Same way you create any other socket. I don't understand the question.
And how can the server application distinguish between the control socket and the transfer sockets?
By being told by the client, and remembering it in some sort of data structure per client. Or maybe you should use different listening ports for control sockets and transfer sockets. Or maybe the transfer socket should be a callback as in FTP.