I would like to use some simple Javascript code I have written, with any public XMPP server using WebSockets. I have seen multiple examples of this and wrote my code accordingly. I am not using any javascript or XMPP libraries and would prefer to keep it that way.
I am opening my websocket with socket = new WebSocket("ws://xmpp.xyz"); and have tried over a dozen servers. My application does not need encryption and therefore doesn't use wss://.
The error returned in chrome's console is "WebSocket connection to 'ws://xmpp.xyz/' failed:". I have been able to successfully open a websocket to the external echo server echo.websocket.events/.ws. Using chrome's network inspect, I see the socket open successfully and my stanza's being sent and received correctly with callback functions.
I now wonder if all the examples I had read, were for servers being hosted in a company network, and none of the public XMPP servers will accept my websocket connection request. If they can accept my request is there something else I need in my url? Based on some of the examples, I have tried a few ports like 80, 5280 and some additions to my url (such as "ws://jabber.org:80/ws/").
Yes, at least one public XMPP server, Tigase.im, does support websockets.
After some light digging though the strophe.js code, I found a second parameter that specified the service as a string. Opening the websocket in pure javascript with the port provided by Wojtek and the protocol string set to xmpp worked.
socket = new WebSocket("wss://tigase.im:5291/","xmpp");
Related
Is there any way that I can write javascript that runs in the browser to create client code and connect to a net.tcp service endpoint and port?
For example, I know that a service contract is exposed at the endpoint https://www.demoexamplething.com:8001/service/mex (example), and is running on .NET server-side code (WCF or something else). How can I use javascript to connect to this endpoint and use its web services?
I know that in a .NET project that I would simply create a "Connected Service" reference and auto-generate client code to work with requests and responses. How can this be done in Javascript?
Is there any way that I can write javascript that runs in the browser to create client code and connect to a net.tcp service endpoint and port?
No, you can't make arbitrary TCP connections from the browser, short of making a browser extension.
For example, I know that a service contract is exposed at the endpoint...
For HTTP requests, you don't need to make a TCP connection. You can use the Fetch API to make an HTTP request. For example:
const res = await fetch('https://example.com');
const data = await res.text();
See also: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
I know that in a .NET project that I would simply create a "Connected Service" reference and auto-generate client code to work with requests and responses.
It's been a long time since I've messed with that... but wasn't there a WSDL or something that helped define the request/response data? I bet someone has made a JavaScript module that wraps Fetch or XHR. I wouldn't know specifically what to search for, but check over on NPM.
since I am learning node.js I was wondering about something:
When I use node.js server to run a websocket, so that clients can connect (like on a website via javascript), it always listens public. Isn't that a security problem, that everyone in the world would be able to send data to the ip:port. They just have to connect to the server via the data that are written anyway within javascript and send / receive data?
I was thinking about a token, which would make sense in Java or Swift etc, but in javascript it can be seen anyway?!
TL;DR: yes, It's totally secure.
Every time the browser sends an HTTP request, there is a port waiting for the server's response. The difference between this to an open port is that an open port is open for everyone on the web. In an HTTP request or web socket, the port opens only to the server.
When I connect to a website who uses websockets, I can get the frames with the Google Developer Tools.
Data from the websocket url
So I would like to get the same data but in a program ( JS, C# ) but I actually have no idea how I should do.
I thought about make a http.request with NodeJS but it's not a http url :/
I thought about make a sample JS client but I couldn't get the data because I wasn't able to send the headers with the 'key'.
The headers
So, I really hope you have a way to help me and sorry for my basic English :(
WebSockets is a standard technology to implement stateful, persistent connections between clients and servers. It has its own protocol ws:// and wss:// (like https://).
What you need is a proper WebSocket client to receive data from the server.
The problem here is WebSockets it's not a protocol per se. There's no concept of request and response. It's like working with TCP sockets.
If you want to work with WebSockets, NodeJS has Socket.IO client API.
In C#, you should take a look at SignalR.
I have a php websocket written as:
$socket = socket_create(AF_INET, SOCK_STREAM, 0);
socket_bind($socket, '127.0.0.1', 8080);
socket_listen($socket);
I run this by php server.php on command line and runs continuously. I am trying to send data from a javascript script to this server. Is it possible? Things I have tried is creating a websocket connection from javascript and using websocket.send(JSON) but it doesnt seem to register in the server.php (or im not sure how to correctly grab the data from the javascript send). Is it possible to send? If so, how could I send?
webSocket is a specific protocol running on top of TCP. It has a specific frame format that must be used in order to communicate with another endpoint using webSocket. It is not just a plain TCP socket as it looks like you are using. Here's a reference document on the webSocket protocol if you want to see how it works.
In fact, webSocket connections are initiated with an http request which are then "upgraded" to the webSocket protocol.
If you're using PHP, you can get a module that speaks the webSocket protocol and use that. I'm not a PHP developer myself, but I hear that Ratchet is a popular way to support webSockets with PHP and there are several others. Here's a related StackOverflow question on webSocket support for PHP.
You might be interested to this http://www.sanwebe.com/2013/05/chat-using-websocket-php-socket
To use socket.io on the client side, usually we start a node.js server and go like this:
<script src="/socket.io/socket.io.js"></script>
or with specific port:
<script src="http://localhost:3700/socket.io/socket.io.js"></script>
Question is:
is it necessary to use node.js server to serve socket.io.js ?
...or is it possible to
make a local copy of socket.io.js instead of goes to server every single time we need socket.io?
like, we go to view source and copy everything we got from the source of script tag,
paste and save it as socket.io-local.js so that next time we use:
<script src="socket.io-local.js"></script>
will that work ?
Updates
Thanks for everyone's great response,
I'm asking this because in the case I'm involved, I don't actually have access to the server:
I am writing the client-side to connect to other developer's Socket Sever which is written in Java.
Therefore I'll have to think a way to work around the fact that I don't have a server there for me.
from what I've been testing,
this way seems to work but I really don't know what's happening behind the scene.
You obviously can host the socket.io client library anywhere and pull it in to a page. However, it will almost certainly not work with your Java-based server.
To understand why, you need to understand what socket.io is really doing behind the scenes; the client library is only a small part of it.
Socket.io actually defines and implements its own protocol for realtime communication between a browser and a server. It does so in a way that supports multiple transports: if—for example—a user's browser or proxy doesn't support WebSockets, it can fall back to long polling.
What the socket.io client actually does is:
Makes a XHR GET request for /socket.io/1. The server responds with a session ID, configured timeouts, and supported transports.
The client chooses the best transport that the user browser supports. In modern browsers, it will use WebSockets.
If WebSockets are supported, it creates a new WebSocket to initiate a WebSocket connection (HTTP GET with Upgrade: websocket header) to a special URL – /socket.io/1/websocket/<session id>.
If WebSockets aren't supported by the browser or fail to connect (there are lots of intermediaries in the wild like proxies, filters, network security devices, and so forth that don't support WebSocket requests), the library falls back to XHR long polling, and makes a XHR request to /socket.io/1/xhr-polling/<sesion id>. The server does not respond to the request until a new message is available or a timeout is reached, at which point the client repeats the XHR request.
Socket.io's server component handles the other end of that mess. It handles all the URLs under /socket.io/, setting up sessions, parsing WebSocket upgrades, actually sending messages, and a bunch of other bookkeeping.
Without all of the services provided by the socket.io server, the client library is pretty useless. It will just make a XHR request to a URL that doesn't exist on your server.
My guess is that your Java-based server just implements the WebSockets protocol. You can connect directly to it using the browser-provided WebSocket APIs.
It is possible that your server does implement the socket.io protocol – there are a few abandoned Java projects to do that – but that's unlikely. Talk with the developer of your server to find out exactly how he's implemented a "socket server."
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-client.js found at the root of this repository.
https://github.com/LearnBoost/socket.io-client
I have a module called shotgun-client that actually wraps socket.io. I needed to serve a custom client script as well as the socket.io client script, but I didn't want every user of my module to have to include multiple script references on their pages.
I found that, when installed, you can serve the generated client script from socket.io by reading the file /node_modules/socket.io/node_modules/socket.io-client/dist/socket.io.js. So my module adds a listener for its own URL and when it serves my custom client script it also serves the socket.io client script with it. Viola! Only a single script reference for the users of my module :)
While this is technically possible, I don't see why you'd need to do that. If you're concerned about reducing the data that goes over the wire, this change won't actually do much beyond the few characters saved in the shorter src tag. Simply changing the location of the JS file on the server won't actually improve performance - the JS has to be sent.
Proper caching (which Socket.IO has) will return a 304 Not Modified (and not re-send the JS file every time you load a page).