I want to create this routine:
I access the /receiver (Receiver)
Receiver is listening for 'hello' event
I access the /emitter (Emitter) from another tab
Emitter fires the 'hello' event
Receiver says alert("Hello world") when 'hello' event is fired
Is it possible using WebSockets? I want to make the API server with Python, and the client with JavaScript.
webSockets connect client and server. The do not directly connect two web pages in two different tabs.
It is possible that two web pages in two different tabs could each connect to the server and the server could then route messages sent from one web page to the other web page. That's how a typical chat program works (which is a classic demo app for webSockets).
Yes, this is possible to build with a server in Python and client in Javascript web page.
You can certainly find many libraries written for webSockets in Python with your own search. Browser Javascript already has webSocket support built in. Many people choose to use socket.io which is a higher-level library built on top of webSocket and there are implementations for socket.io in many languages (including Javascript for the browser and Python for the server).
WebSocket is used when you need a persistent, web-friendly connection with or without a browser. If you just need to merely communicate among tabs in the same browser instance, you can use localStorage (which fires an StorageEvent event) even if you are offline.
If you potentially need the emitter to be accessed by another browser out on the web, or if the emitter was not a browser web-app (e.g., an IoT use case), then you would need WebSocket. Then one good solution would be a simple publish/subscribe mechanism using WebSocket. Here's a good Angular library that a colleague wrote that might help you:
https://github.com/kaazing/tutorials
Full disclosure: I work for Kaazing
Related
We have two applications, one called flexOS locally on "the server", and one called flexVisu remote on "the client". The first one is doing the job, collection data and such things.
Historically those two applications are able to communicate via TCP/IP sockets and a proprietary binary protocol.
Now we want to replace the client application flexVisu with a web page hosted on the IIS locally on the server. Every web browser on every device should be able to display these web page(s).
Firstly we experimented with an additional application (flexVisuWebServer) on the IIS side that basically hosted a web socket server and translated the json data from the client into binary data for the server and vice versa.
But this always requires a http connection and a wss connection to be open at the same time.
I don't know why, but I don't like the idea of using javascript on the client to handle all the data processing to display the server data.
I think that it would be much easier if I wrote an asp.Net c# application that handles the connection to "the server" via our proprietary TCP/IP protocol. That way no conversion of data between binary and json format must be done, and the web page itself can be also written in C#.
This approach much more resembles the current approach with flexVisu connecting directly to flexOS, the binary data is directly used to fill in Windows Forms controls.
What am I missing here?
Would the asp.Net application be able to connect to a tcp socket and use our own protocol?
[Edit: 2021-02-09 at 16:18 localtime]:
I managed to use our proprietary TCP/IP protocol to connect from the web server to the flexOS in the page_load of the asp.net web page.
So basically it should not be a problem to use the underlying library to read data directly from the flexOS.
OT: Should i post subsequent ASP.Net questions here too, or open some more questions?
We decided to follow this concept:
the webpage is using a websocket connection to our application flexVisuWebServer and this application uses our propietary TCP/IP protocoll to talk with flexOS.
Basically, I want to make a peer to peer architecture, using JavaScript (Ionic).
Since, JS cannot create sockets/etc; a NodeJS server has to be introduced between the clients; acting as the Socket.IO server between the clients.
The problem with this, is that the Socket.IO (NodeJS) server would need to be automatically found within the local network -- by the clients (instead of hardcoded/configured).
Are there any ways to implement such a thing; or alternatives to this architecture?
Thanks for the help!
Are there any ways to implement such a thing; or alternatives to this architecture?
Currently your architecture is using a browser app plus a Node app that users need to have on their network just to create TCP connections.
What you can do instead is create an Electron app that combines a Node app, a browser app, and a browser itself. See:
https://electron.atom.io/
With Electron you can write your frontend code almost the same way as for the regular browser, but you can use the entire Node API including the TCP sockets so there will be no need to create a separate Node app and to search for that app in the network. This can greatly simplify your architecture.
Note: this is not an answer to the first part of the question: "How to detect a server in the network using JS?" but to the second part of the question: "Are there any ways to implement such a thing; or alternatives to this architecture?" Detecting the servers on the local network with client-side JavaScript will not be easy - and in fact it shouldn't be even possible because websites being able to scan your LAN for active services would be a serious problem for privacy and security.
I am interested to know if anyone has built a javascript websocket listener for a browser. Basically the server side of a websocket that runs in a client. This would allow messages to be sent to the client directly. Why? Because instead of having a Node.js, python, java, etc, server process sitting on or near the client/browser, I can just use a thread in the browser as a listening server thread. I don't think that any browsers support this currently.
I've run across answers like this: https://news.ycombinator.com/item?id=2316132
Just curious if anyone has done this. I believe that the current Websockets spec does not support listeners on the browser. It would make the deployment of various peer-to-peer applications a bit easier to deploy.
WebRTC allows for peer-to-peer connections to be made between browsers.
You would still need a server in order for individual users to discover each other but then they could connect directly to each other rather than having to pass all their traffic via a central server.
The idea.
You can use a simple echo server written in any language. Your script can send the data to the server then get it back, handle it on the same page with different functions/classes emulating the real server.
An example: http://www.websocket.org/echo.html
Then, you can think about different formats of packets to/from server to diffirentiate them inside one script.
I'm fairly new to the world of JS and its abundance of libraries. I'm looking to get into a project that involves network communication (sockets) between clients and a server. In a world with tons of libraries, I cannot make a decision as to which to use. I'm looking for something that will bring efficiency and stability.
I've been told that Node.js is like the middleman between you, as the developer, and Socket.IO. I've been told it's a huge framework that you may not use at least half of. I've been told that to maximize efficiency, you're better off using Socket.IO to make your own functionalities. I've done some research on my own and found that Socket.IO NEEDS Node.js and Node.js DOESN'T NEED Socket.IO. Which is completely opposite of what I was told. Then I find that most developers use both Socket.IO and Node.js at the same time?
Like I said, I'm fairly new, but I cannot find the right resources that would help me accomplish a websocket communication between a client and a server with maximum efficiency, or at least explain the difference between Socket.IO and Node.js. If anyone here could, please let me know! I would greatly appreciate it.
node.js is a general purpose javascript-based run-time environment (somewhat similar to other language runtimes like python in scope). You can create apps in it that don't even use the network. It is often used as a web server for created web apps and has a great set of tools and rich library of add-ons for doing so. It does not need socket.io.
socket.io is a specific library to enable web-socket-like communication between a client and a server (e.g. a chat room app is the canonical example). The server side of socket.io assumes a javascript run-time (because it's written in javascript) so that generally means node.js (though I'm not sure if a different JS runtime could perhaps be substituted).
You can think of node.js like the platform and socket.io like a specific tool to do a specific job that runs on that platform. You would use socket.io (on top of node.js) if you needed web socket connectivity between client and server.
You would use only node.js if you need any of the other things node is good at, but did not need websocket connectivity.
websockets themselves can be programmed on the server side without socket.io and without node.js. They could be programmed in strait C++ or in Java. But socket.io (running in node) provides a very easy way to set them up because the socket.io library covers both client and server in one library and one API and it's all in the same language (javascript). Look at the chat room app example on the socket.io site and you will be unlikely to find any other solution that can accomplish that in as few lines of code as it does and with the same interface on client and server.
If you were only setting up a websocket server (no web server or web app of any kind), you could still use node and socket.io and use it just for the websocket server and it would still be quite efficient. While node is capable of doing lots of other things, if you don't configure and install all those other things, they aren't costing you anything - they are just unused capabilities that aren't running.
I should add that one other thing the socket.io library does is it handles an auto-negotiation between client and server to find the best channel for the client and server to communicate on. If websockets are available, then socket.io will likely use them, but if web sockets are not available, socket.io has alternate methods that will work (even in older browsers). That functionality comes for free in socket.io without you even doing anything.
In case this isn't completely clear to you, websockets are typically used to provide real-time communication between client and server. While clients can ask for data from a server at any time with an ajax call or a web page request, what websockets allow is a two way real-time communication between client and server and the biggest advantage of websockets is that a server can send a client real-time data at any time while they are connected.
For example, I have a web page that receives real-time data from my server anytime the web page is open. The web page is served over the typical node.js web server installation, but the real-time data is sent from server to client over a websocket connection.
In addition, if there's a chatty conversation happening between client and server, websockets can be much more efficient than a series of ajax calls because with a websocket, a connection is opened once and used repeatedly whereas with ajax, each successive ajax call is like a new connection.
Node.js is a runtime environment. It's a javascript engine with a standard library built around asynchronous I/O. It plays the same role that Java, Python, Ruby, .NET, etc., play for many other web applications.
I've been told it's a huge framework that you may not use at least half of.
It might be true that most people never use most of the standard library, but I wouldn't think it's more true of Node.js than other runtimes. "Framework" isn't an accurate word to describe it.
I've been told that to maximize efficiency, you're better off using Socket.IO to make your own functionalities.
Whoever told you that was mistaken, or meant that to maximize efficiency, you're better off using [Node.js and] Socket.IO [instead of other solutions]. Many other non-Node.js solutions require a single thread or process per connection, which limits the number of simultaneous connections a server can handle. Node.js is built around asynchronous I/O which is better for keeping many connections open at once, and Socket.IO is a library for Node.js for using WebSockets.
TL;DR: Socket.IO can fire events in realtime between your client and server, so there is no need for you to reload the page to notice something changing. This can be used for "live" applications like collaborative drawing, live chats, online games and more!
I have recently discovered HTML 5's support for the WebSocket protocol. I began idly experimenting with it and I decided to undertake a simple chat program project. For it, I'd like to be able write a WebSocket server and have it serve users inside of a blog post, using Google's Blogger website.
The server would be written in Javascript and would have all the code needed to send one person's "conversation line" to all other WebSocket connections connected to it. Later, I may implement "chatrooms" where each line is simply redirected to certain users.
My first question: would it be possible to create a Javascript-based WebSocket server? I've researched a bit, and it seems that all server implementations were in PHP or some server-side language similar to that. Would it be possible to write a WebSocket server with Javascript?
The server implementation would be inside of a webpage, so as long as the blog is up, the server would work as well. My blog can be found here. The client's code would be like this:
server = "http://imdmstromyf8imdcaptomysl.blogspot.com/post_that_handles_chat";
connection = new WebSocket (server);
The problem is, a WebSocket runs on its own protocol (ws:// or wss://), so changing "http://" to "wss://" would not work. Could I tunnel the WebSocket protocol through HTTP? If I did, I would probably have to use Ajax, but avoiding that is the reason I wanted a WebSocket chat program.
Blogger has a place where you can insert your own HTML; would it be possible to use PHP tags to delineate the code from HTML?
I would just like to know whether it's possible to do what I want, and if it is, some implementation tips or (even better) some example code to use.
"The server implementation would be inside of a webpage"
A server implementation is not in a web page. Not sure what you meant here. You may want to edit your question.
Node.js is library written in JavaScript for use on the server. Google this and you should find many ways of getting started on running a WebSockets. To connect to the client, you will be using JavaScript as well, which you should again select a library that supports web sockets.
Additionally, you will need to verify the client' Browser supports it.
You can look at browsers that support web sockets here
Here is a jQuery plugin for web sockets