So basically I want to use NodeJS sockets to create a server as well as clients to speak between each other, my question is if a NodeJS socket can expect data from other languages, for example a socket in C++ send data to my program in NodeJS? I saw examples that always runs express for the server, I need to create the server in the same application. Thanks in advance and excuse my english.
my question is if a NodeJS socket can expect data from other languages
Yes. These are just normal network sockets on which you send/receive arbitrary data. Nothing about them are specific to Node.js
I saw examples that always runs express for the server
Express is a framework for handling HTTP requests. HTTP is a protocol that runs on top of a TCP socket. Express is irrelevant here, unless you want to use HTTP... in which case you'd use Express in conjunction with Node.js' built in HTTP library.
Don't confuse Web Sockets with normal sockets. They're really unrelated. Web Sockets are an abstraction on top of HTTP which emulate socket behavior between browsers and servers, but they really have nothing to do with each other, directly. You can't use a Web Socket client to connect to an arbitrary port on something.
sockets to create a server as well as clients to speak between each other
You, sir, need socket.io
Related
I am wondering if someone has used the socket.io-client library for communicating between servers instead of communicating between browsers to server.
Is this kosher?
Is the behavior of the library pretty much the same when the client library is running on a server vs running in the browser?
Can the socket.io-server library initialize connections with clients, or do socket.io-clients need to initialize connections?
Is this kosher?
Yes, that is exactly what the socket.io-client is designed for. It works great for communicating between two servers.
Is the behavior of the library pretty much the same when the client
library is running on a server vs running in the browser?
Yes, the behavior is identical. The only difference under the covers is that the browser implementation is built on top of the browser's webSocket support whereas the server-side client uses the socket.io webSocket implementation.
Can the socket.io-server library initialize connections with clients,
or do socket.io-clients need to initialize connections?
Only socket.io servers are "listening" for incoming connections. Somebody has to connect TO the socket.io server. You can't connect TO a socket.io client. A client must connect to a server. So, a socket.io client (which can be either in a browser or on a server) must be the one that creates the connection. Once connected, data can be sent either way on that connection.
Considering you are talking about the JavaScript version of the socket.io-client:
Yes, of course it is legitimate to use it server-side. it is just a "client" library, not only a "client-SIDE" library.
The behavior is the same, yes.
Clients need to initialize connections.
There is a server side usage example the Socket.io-client documentation
Other versions of the socket.io-client are also available in different languages (swift, java, CPP), that you can find on their Github page.
i wrote a simple C++ Server which is waiting for clients.
I want users to be able to connect to this client by opening a webpage without installing anything. So the only thing that comes to my mind is using Javascript. Since the server needs to react in realtime later on ( performance is an issue ) sending data with POST/GET is not wanted.
Is this possible with Node.js or Socket.io ? I am trying to find a good example but i only find node.js servers. And when i open a socket with
var socket = io.connect('localhost:25003');
it is sending weird data.
Does anyone have a simple example with a javascript client that can connect to anything and send raw data?
You cannot do plain TCP from browsers (unless you're writing a browser addon/extension or using something like a Java applet or a Flash bridge possibly). Socket.IO always uses HTTP. However those HTTP connections can then be upgraded to WebSockets or other protocols, depending on what the browser and/or Internet connection supports.
The "weird data" you're seeing is probably an HTTP message.
I am having trouble understanding the difference between net.createserver and http.createserver in node.js.
I have read the documentation for both methods located at these two urls
https://nodejs.org/api/net.html#/net_net,
https://nodejs.org/api/http.html#/http_class_http_server.
I understand that http.createserver creates an http server. However, the documentation says that net.createserver creates a tcp server. I understand that tcp is the transmission protocol that http is on top of and that http servers are set up to read http request headers. I also understand the concept of even emitters in node.js pretty well. However, I don't understand this notion of a tcp server and why one would be made in node.js. The context is I am coding a chat application example in the "node.js in action" book.
http.createServer() sets up a server that handles the HTTP protocol, which is indeed transmitted over tcp. net.createServer() creates a server that simply understands when a TCP connection has happened, and data has been transmitted, and so on, but doesn't know anything about whether a valid HTTP request has been received, etc.
If you are writing a web server, favor http.createServer() over net.createServer() as it will save you a lot of work. If you are writing some other kind of server, do not use http.createServer().
I don't know much of a Node.js, but I know something about networks. HTTP is a protocol that works on 7th (Application) layer of model OSI. TCP is protocol that works on 4th (Transport) layer of model OSI. As you said, yes HTTP works on top of the TCP. The option of creating HTTP server by http.createServer() is there so you don't have to implement it by yourself by using net.createServer(). The protocol TCP might by used by lot of applications, you might create your own, or implement some different protocol than HTTP, for example: FTP, DNS, SMTP, Telnet and much much more.
Straight from the Node Net documentation. NET is the basic bare-bones server you can create. It's particularly useful for setting up a cluster of servers and allows simple connections but on that you'll want communication protocols, namely HTTP, which HTTP is in fact a NET server at it's core.
The net module provides an asynchronous network API for creating stream-based TCP or IPC servers (net.createServer()) and clients (net.createConnection()).
And from the HTTP documentation. HTTP is the common way to transmit large sets of data as requested by the client and then a response is generated. It's the standard way of communicating over the internet and introduces the concept of handshakes and is done through REST protocol, you know the usual request and response way of communicating.
The HTTP interfaces in Node.js are designed to support many features of the protocol which have been traditionally difficult to use. In particular, large, possibly chunk-encoded, messages. The interface is careful to never buffer entire requests or responses — the user is able to stream data.
Websockets are an upgrade over the HTTP headers and offer low latency and less server load and are a much more minimal conversation. If you're talking peer to peer communication, that's the way you'll want to go.
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.
I have been breaking my head on understanding what exactly is socket.io and its role in the whole persistent communication between client and server in general. Some fundamental questions that keep coming up in my mind are :
Are node.js and socket.io server different ways of doing the same thing ? Like lighthttpd and apache ?
Why should I use socket.io server if I have node.js ?
Can I use socket.io client with another server side programming language like PHP ?
Are there alternatives to using socket.io client ?
Is socket.io client just another javascript library for websocket communication ?
Thanks :)
The Socket.IO server accepts connections from Socket.IO clients. This is not any different than any other server (such as a web server like Apache) accepting a connection from a client (such as a web browser like Internet Explorer).
Node.js is a platform built on top of the V8 JavaScript engine, which comes with a convenient library usually used for web and network applications. Socket.IO is a web-socket-like communication wrapper and RPC which enables servers and clients to communicate over a variety of transports (every thing from long-polling JSON to real Web Sockets). Generally, the Socket.IO server code runs in your JavaScript application running on top of Node.js, and the Socket.IO client runs in your JavaScript on a web browser. (Note that you can run the Socket.IO client in your Node.js application to, which I have used in the past as a quick RPC between multiple Node.js applications.)
There are Socket.IO clients available for many languages, and yes I believe there is one for PHP but I haven't used it personally.
If you want to communicate with a Socket.IO server, you must use a Socket.IO client. It is a protocol all on its own.
Are node.js and socket.io server different ways of doing the same thing ?
SocketIO is actually a I/O engine that permits realtime communication between client and server, unlike classic HTTP requests.
Why should I use socket.io server if I have node.js ?
Since both are differents, we can't compare.
Can I use socket.io client with another server side programming language like PHP ?
No, because socketIO server run in NodeJS environment.
Client first make a HTTP request, then socketIO send a static JS script to client.
This script establish the two-way communication.
But you can use socketIO server with different socketIO client implementation.
Are there alternatives to using socket.io client ?
Any socketIO client implementation can do the job since they connected to server.
But beware of asynchronous way of communication, like in Java or PHP.
Is socket.io client just another javascript library for websocket communication ?
Yes it is, but socketIO aims on reliability and easy to use, and also do best effort : It choose the best transport available for client.
Hope it helps !
Are node.js and socket.io server different ways of doing the same thing ? Like lighthttpd and apache ?
Socket.io is a framework/library for node.js
Why should I use socket.io server if I have node.js ?
It's a framework designed for two-way communication, use it if you want
Can I use socket.io client with another server side programming language like PHP ?
Technically yes. But then you would have to reimplement socket.io server in that other language to match it.
Are there alternatives to using socket.io client ?
Lots of, google for websocket/real time communication in [here put your language]
Is socket.io client just another javascript library for websocket communication ?
Socket.io client is a JavaScript library compatibile with socket.io server (which is JavaScript library as well, only on the server side, i.e. Node.js)