Is there a way to perform GET and POST requests using only socket.io-client? Regardless of the server framework.
Something like socket.emit('/endpoint', req).
You are confusing Websocket protocol with HTTP (another protocol). GET and POST are HTTP methods and have nothing to do with Websockets.
The only similarity between Websocket and HTTP is, that both are using TCP on the layer below.
Related
We are using IIS and ISAPI DLL's to deliver our web application. We can see the websocket upgrade request coming from the browser in our ISAPI application. We could accept the request and pass the connection to a thread to continue the conversation. The thread would now be the "websocket server" so in this sense we are able to handle incoming http (and https on 443) then switch from http to websocket, is that right?
I am assuming Microsoft's implementation of websockets only works with asp.net?
Some people have said to me "put the websocket server on a different port and have the javascript connect to that port." But, then the websocket server is not using HTTPS (SSL).
For example:
var socket = new WebSocket('ws://echo.websocket.org');
I have lots of books and examples but this simple issue is eluding me.
The thread would now be the "websocket server" so in this sense we are able to handle incoming http (and https on 443) then switch from http to websocket, is that right?
Yes, if the client side send the request which contains the Upgrade: websocket, the websocket serve will switch from http to websocket.
I am assuming Microsoft's implementation of websockets only works with asp.net?
If you means the websocket .net library, it will just work with .net application like asp.net, it is developed based on the .net framework.
For example: var socket = new WebSocket('ws://echo.websocket.org');
As far as I know, the websocket also contains the secure connection like https.
Like below image shows:
More details about the difference between http and websocket, you could refer to below article:
https://developerinsider.co/difference-between-http-and-http-2-0-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 am using Socket.IO with a MEAN stack and it's been excellent for low latency and bidirectional communication, but what would be the major draw back for using it for relatively static data as well as dynamic?
My assumption is that it would be more apt for sending more dynamic content. That being said, once a socket connection is established, how relevant is the amount of communication being done? Is there a time where it would be more appropriate to use http instead when a connection is constantly established throughout the user's direct interaction with the application?
Thanks!
WebSockets are a bidirectional data exchange within a HTTP connection. So the question is not if you use HTTP or WebSockets, because there is no WebSockets without HTTP. WebSockets are often confused with simple (BSD) sockets, but WebSockets are actually a socket-like layer inside a HTTP connection which is inside a TCP connection which uses "real" sockets. Or for anybody familiar with OSI layers: it as a layer 4 (transport) encapsulated inside layer 7 (application) and the main reason for doing it this strange way instead of using layer 4 directly is that plain sockets to ports outside of HTTP, SMTP and a few other protocols are no longer possible because of all the port blocking firewalls.
So the question should be more if you use simple HTTP or if you need to use WebSockets (inside HTTP).
With simple HTTP the client sends a request and the server sends the response back. The format is well defined and browser and server transparently support compression, caching and other optimizations. But this simple request-response pattern is limited, because there is no way to push data from server to client or to have a more (BSD) socket like behavior where both client and server can send any data at any time. There are various more or less good workarounds for this, like long polling.
WebSockets gives you a bidirectional communication, which makes it possible for the server to push data to the client or to send data in both directions at any time. And once the WebSocket connection is established by upgrading an existing HTTP connection the overhead for the data itself is very small, much smaller then with a full new HTTP request. While this sounds good you loose all the advantages of simple request-response HTTP like caching at the client or in proxies. And because client and server need resources to keep the underlying TCP connection open it needs more resources, which can be relevant for a busy server. Also, WebSockets might give you more trouble with middleboxes (like proxies or firewalls) then simple HTTP does.
In summary: if you don't need the advantages of WebSockets stay with simple request-response HTTP.
This may seem like a stupid question but is it possible to establish a connection between a webserver and a nodejs application? I know that I can make requests from the nodejs server but is it possible to do something the other way around?
Assuming the webserver in question allows you to make outgoing network connections, you just use whatever features it has for doing so to connect to your node.js server and make a request, whether an HTTP request or some generic TCP request. For example, if the webserver were running PHP, you'd probably use the cURL PHP module to make an HTTP connection, or fsockopen() along with fread() and fwrite() for a raw TCP connection.
Note that some hosting arrangements may disallow outgoing connections.
You can use the request-library to do a HTTP request to another node.js server.
Faye supports cross-domain subscription. Here is an excerpt from their docs:
Cross-domain operation
Faye clients and servers transparently support
cross-domain communication, so your client can connect
to a server on any domain you like without further configuration.
Anyone knows how it achieves it?
Faye uses JSONP to send a handshake request to the server when it's cross-domain, as the author of Faye explains in his reply here. It then selects a new transport from a list, in order of preference: WebSocket, EventSource, XHR, CORS and JSON-P. Note that WebSockets, once established, can also work cross-domain as previously discussed here.