I am building a chat server which uses a custom protocol for communicating with clients over sockets. The client sends specific strings to the server and the server must take an appropriate action based on these non-standard messages. I can't change this protocol, nor do I have any access to the underlying client code.
My question is, can I use the node.js socket.io package to power the server socket communication if I have no idea how the client is handling it's socket activity? I'm asking because, reading through the socket.io docs, each time I push anything through a socket an 'event' is associated with each action.
Is it possible to send a very exact message to the client from the server with this 'event' bundled in? Am I better off using the websockets package?
Can a socket.io server communicate with a non-socket.io client
No. A socket.io server requires both the webSocket protocol for connection initiation and the socket.io format on top of that. So, a socket.io server can only talk to a socket.io client and vice versa.
If your chat client uses a custom protocol, then you need to implement a TCP server that also speaks that custom protocol (whatever it is).
If you can modify the client, then you can modify it to use a socket.io client and then you can send your chat messages via socket.io where your socket.io server can then receive those messages.
The client sends specific strings to the server and the server must take an appropriate action based on these non-standard messages. I can't change this protocol, nor do I have any access to the underlying client code.
Then, you have to implement a server that speaks your custom client protocol based on whatever the underlying protocol is for the client. There is no other way around it.
I'm asking because, reading through the socket.io docs, each time I push anything through a socket an 'event' is associated with each action.
This is how the socket.io layer works. It sends a message and (optional) data. This can always be used to just send data by just declaring a generic data message and then just listening for the data message on the other end. But, this assumes you can modify both client and server to work this way. If you can't modify your client to use the socket.io protocol, then you can't use socket.io.
Related
I having some doubts that:-
what is need to use the socket.io client we can use only the socket.io server to stop refreshing the app.
what is different between the socket.io client and socket.io server.
check this link
socket-io.client is the code for the client-side implementation of socket.io. That code may be used either by a browser client or by a server process that is initiating a socket.io connection to some other server (thus playing the client-side role in a socket.io connection).
A server that is not initiating socket.io connections to other servers would not use this code. This has been made a little more confusing that it probably should be because when using socket.io, it appears that both client and server are using the same socket.io.js file (because they both refer to a file with the same name), but is not actually the case. The server is using a different file than the client.
From the Github page for socket-io.client:
A standalone build of socket.io-client is exposed automatically by the socket.io server as /socket.io/socket.io.js. Alternatively you can serve the file socket.io.js found at the root of this repository.
Keep in mind that there are unique features that belong to client and server so it should not be a surprise that they use some different code. Though they share code for parsing the protocol and things like that, the server has the ability to run a server or hook into an existing web server and it has methods like .join() and .leave() and data structures that keep track of all the connected sockets and is expected to live in the node.js environment. The client has the ability to initiate a connection (send the right http request), do polling if webSockets are not supported, build on a native webSocket implementation if present, etc....
I am using a websocket library on server for establishing socket connection.
https://github.com/websockets/ws
I have a more than one server in cluster, I want to know how can I use same socket connection object on another server in cluster.
And also I want to know what is the best option for webchat implementation native websocket or socket.io
You cannot use the same actual socket object across multiple servers. The socket object represents a socket connection between a client and one physical server process. It is possible to build a virtual socket object that would know what server its connection is on, send that server a message to then send out over the actual socket from that other server.
The socket.io/redis adapter is one such virtual ways of doing this. You set up a node.js cluster and you use the redis adapter with socket.io. It uses a central redis-based store to keep track of which serve process each physical connection is one. Then, when you want to send a message to a particular client from any of the server processes, you send that message through socket.io and it looks up for you in the redis database where that socket is connected, contacts that actual server and asks it to send the message to that particular client over the socket.io connection that is currently present on that other server process. Similarly, you can broadcast to groups of sockets and it will do all the work under the covers of making sure the message gets to the clients no matter which actual server they are connected to.
You could surely build something similar yourself for plain webSocket connections and others have built pieces of it. I'm not familiar enough with what exists out there in the wild to offer any recommendations for a plain webSocket. There plenty of articles on scaling webSocket servers horizontally which you can find with Google and read to get started if you want to do it with a plain webSocket.
I implemented 2 webservers with express. One is the main, one is a microservice.
They are communicating through a HTTP REST API, and we had historically a socket.io server started on the microservice to watch the up/down status from the main server.
----HTTP-----
[main server] [microservice]
--socket.io--
I then realized that socket.io is not the right tool for that. So I decided to trade socket.io for a raw TCP socket.
So the question is : Is that possible to start the http server "ON TOP" of a raw TCP server (on the same port) ? (allowing to connect via TCP client AND to send HTTP requests ?)
I have this so far :
const app = express();
const server = http.createServer(app);
// const io = sio(server);
server.listen(config.port, config.ip, callback);
and I'm trying to integrate with this
What I'm trying to achieve, and achieved successuly with socket.io, is starting a socket server on the microservice, connect to it on the main server, keep it alive, and watch for events to keep a global variable boolean "connected" in sync with it. I'm using this variable to aknowledge the my frontend of microservice state, also to pre-check if I should try to request the microservice when requested, and also for loggin purposes. I'd like to avoid manual polling, firstly for maintenability, and also for realtime purpose.
Is that possible to start the http server "ON TOP" of a raw TCP server (on the same port) ?
Sort of, not really. HTTP runs on top of TCP. So, you could technically open a raw TCP server and then write your own code to parse incoming HTTP requests and send out legal HTTP responses. But, now you've just written your own HTTP server so it's no longer raw TCP.
The challenge with trying to have a single server that accepts both HTTP and some other protocol is that your server has to be able to figure out for any given incoming packets, what it is supposed to do with it. Is it an HTTP request? Or is it your other type of custom request. It would be technically feasible to write such a thing.
Or, you could use the webSocket technique that starts out as an HTTP request, but requests an upgrade to some other protocol using the upgrade header. It is fully defined in the http spec how to do this.
But, unless you have some network restriction that you can only have one server or one open port, I'd ask why? It's a complicated way to do things. It doesn't really cost anything to just use a different port and a different listening server for the different type of communication. And, when each server is listening only for one type of traffic, things are a heck of a lot simpler. You can use a standard HTTP server for your HTTP requests and you can use your own custom TCP server for your custom TCP requests.
I can't really tell from your question what the real problem is here that you're trying to solve. If you just want to test if your HTTP server is up/down, then use some external process that just queries one of your HTTP REST API calls every once in a while and then discerns whether the server is responding as expected. There are many existing bodies of code that can be configured to do this too (it's a common task to check on the well being of a web server).
The code you link to shows a sample server that just sends back any message that it receives (called an echo server). This is just a classic test server for a client to connect to as a test. The second code block is a sample piece of client code to connect to a server, send a short message and then disconnect.
From your comments:
The underlying TCP server wouldn't even be used for messaging, it just would be used to watch connect/disconnect events
The http server already inherits from a TCP server so it has all the same events for the server itself. You can see all those events in the http server doc. I don't know exactly what you want, but there are server lifetime events such as:
listening (server now listening)
close (server now closed)
And, there are server activity events such as:
connect (new client connected)
request (new client issues a request)
And, from the request event, you can get both the httpClientRequest and httpServerResponse objects which allow you to monitor the lifetime of an individual connection, including event get the actual socket object of an incoming connection.
Here's a code example for the connect event right in the http server doc.
I have a program in an embedded device that outputs an xml string to a socket. The embedded device has lighthttpd has a web server. I want to use a web based client (no flash/silverlight) to connect to the socket and pull the xml data every second.
I looked at Node.js with Socket.io to get what I want to do, but I am not clear about how to proceed. Searching through the Node.js and Socket.io documentation and examples I see standard client-server behavior, nothing regarding what I am trying to do.
Basically, the web server is just there to accept a connection from a client on the socket that the embedded application is outputting data to. Basically the web server's purpose is to just let the client retrieve data from the raw tcp socket that the embedded application is writing to. Please advice.
I solved the problem using Websockify, which acts as bridge between a TCP Socket and a browser.
The html client will connect to a websocket, and Websockify will listen on the websocket port and transmit data between the websocket and the tcp socket.
Web browsers have the ability to do HTTP requests (which can be web page requests or Ajax requests for data) and webSocket connections. You will need to pick one of these two mechanisms if you're sticking with stock browser access.
If the lighthttpd web server in the embedded device does not support webSockets, then your choice will like be an Ajax call from the browser to your server. This is basically just an HTTP request that make return something different than a web page (often JSON data) and is designed to fetch data from the server into a web client.
If the lighthttpd web server does support webSockets, then you could use a webSocket connection to fetch the data too. This has an advantage of being a persistent connection and allows for the server to directly send data to the client (without the client even requesting more data) whenever it wants to (more efficient for constant updates).
An Ajax connection is generally not persistent. A client sends an Ajax request, the server returns the answer and the connection is closed. The next request starts a new Ajax request.
Either Ajax requests or webSocket connections should work just fine for your use. All browsers still in use support Ajax. WebSockets are supported in modern browsers (IE10 and higher).
Once you decide upon a client connection strategy, then you'd build your web app on the embedded device that served as the middleman between the browser and the data on the embedded device. It would collect the appropriate data from the embedded device and then be able to send that to browser clients that connected and requested the data.
I'm not sure exactly why you mentioned node.js. In this circumstance, it would be used as the web server and the environment for building your app and the logic that collects the data from your device and feeds it to the requesting web browser, but it sounds like you already have lighthttpd for this purpose. Personally, I recommend node.js if it works in your environment. Combined with socket.io (for webSocket support), it's a very nice way to connect browsers directly to an embedded device. I have an attic fan controller written in node.js and running on a Raspberry Pi. The node.js app monitors temperature probes and controls relays that switch attic fans and node.js also serves as a web server for me to administer and monitor the node.js. All-in-all, it's a pretty slick environment if you already know and like programming in Javascript and there's a rich set of add-in modules to extend its capabilities available through NPM. If, however, your embedded device isn't a common device that there is already support for node.js on or it doesn't already have node.js on it, then you'd be facing a porting tasks to make node.js run on it which might be more work than using some other development environment that already runs on the device like lighthttpd.
The requirements of the project are:
If any user updates a record (any record), all relevant parties must be notified immediately by displaying an alert somewhere in the webpage. In previous projects, the browser would poll the server for any relevant changes every N seconds.
I have been reading on web sockets and think this is the prefect solution for this problem (I do not like polling).
I have some questions regarding Web Sockets in JavaEE. Please correct me if I am wrong.
Web Socket seems to be supported on Glassfish server not in latest version of JBoss/Wildfly.
If 1000 clients are logged in and connected to the server using Web Socket, does the server have 1000 separate sockets open for each connection? Or is the implementation similar to Node.js where a single server socket is used for all client connections. This information does not seem to be documented anywhere in JavaEE tutorials.
Websockets are TCP connections and the websocket protocol is simply an upgrade of the TCP protocol with an handshake procedure similar to the http protocol, but the websocket protocol is bidirectional.
I don't think you are getting a single web socket in Node.js. You have a connection per logged client anyway. In Node.js you have the broadcast, but this is the same as sending a message to any logged client through the related web socket. You have the same functionality in glassfish, where you simply loop on all the web sockets:
http://www.byteslounge.com/tutorials/java-ee-html5-websockets-with-multiple-clients-example
and you can do the same in weblogic:
https://docs.oracle.com/middleware/1212/wls/WLPRG/websockets.htm#WLPRG872
This is the same as Node.js without any wrapper.