Sorry for the newb question, but as I just started really figuring out TCP and UDP sockets this year. (used them cluelessly in the past).
What’s a WebSocket? Can I use a TCPSocket in place of it? Seems JS has them “built in” but it seems that Xojo does not?
Looking to build a StreamDeck Plugin in Xojo instead of JS, and perhaps the WS will be a stumbling block?
WebSocket is probably a really shitty name
Its a protocol just like HTTP, FTP, SMTP/POP etc done over a TCP/IP connection
Heres the RFC https://tools.ietf.org/html/rfc6455
And about there my knowledge of them stops
Ah. Thanks!
Yikes!
My app needed to exchange an arbitrary amount of data between its Xojo side and a specific HTMLViewer. That was because the available data exchange methods (setting the status or title and getting events) seemed a bit arbitrary, different on different platforms, and subject to change.
So I wrote a websocket server for the Xojo side to effect this. It’s not a general one, it waits for a connection and having got that then settles down and waits for work requests. How efficient that is - using sockets to communicate between different parts of a program, I know not. However, it works well and without apparent delays.
Did you have a specific question?
Ok, so it sounds like my question has been answered, a WebSocket is a specific protocol, not a Socket like TCP or UDP and there IS NOT a websocket object in Xojo.
I’m not sure if I need a server or client for communication with a StreamDeck. In JS, they just do:
websocket = new WebSocket("ws://127.0.0.1:" + inPort);
and then
websocket.send(JSON.stringify(json));
to send data and
websocket.onmessage = function (evt)
{
// Received message from Stream Deck
var jsonObj = JSON.parse(evt.data);
(etc)
to receive data.
A TCP socket & connect to 127.0.0.1 on whatever remote port and then off you go
But knowing the protocol will help as there may be special framing for sending and receiving data that you will need to handle
That would not surprise me in the least
I guess I could try that and see. It seems to pass JSON strings back and forth which Xojo has a good handle on…
There must be a reason they use a WebSocket though…
Havent read the WebSocket RFC so there may be something special about how the protocol works that I’m un aware of
Others might know ?
@Tim ? @HalGumbert ?
I don’t have much info on it, just enough to know that the parts I need aren’t currently implemented in Xojo code that I have access to.
No clue. Not sure I ever used WebSocket.
My implementation subclasses SSLSocket. The mechanism just passes data back and forth. It’s useful because it’s natively built into javascript, so there’s nothing to implement within the HTMLViewer; you just use it.
On the Xojo side all the protocol work is done by the DataAvailable event handler. But since the protocol used between web servers and browsers is HTTP, whereas for websockets its just raw data, there has to be an initial protocol exchange between the two sides to establish that they are switching away from HTTP to use websocket protocol.
Note: JSON is not involved at all (although nothing stops your data being JSON stuff if you want it to be, but I know nothing of JSON).
I tested my setup with different packet sizes, I could send 10Mbyte packets from one side to the other with no difficulty.
Is your implementation sharable? I’m still on a low priority quest to implement a Discord bot in Xojo.
Yes I could send you the WebSocket class and the Server thread and some notes I’ve made.
Remember that:
the server and client are within the same app on the same machine
the server thread is intended to wait for a connection from one client (a particular HTMLViewer) and then enter a loop waiting for work items (may be sent from another threads or from the HTMLViewer) which it then processes. So it’s not a general server in the sense of handling lots of connections.
I found one by Kem…
I’d mentioned that one in a different thread a while back
Let me see if I can find that thread as there were comments about this
There were additional comments after my post about this from other users
Any idea why an application that’s only speaking to a plugin on the same computer would use a WebSocket to speak to the plugin instead of just using a simple TCPSocket?
I guess it would make sense if it needed to communicate over the internet, but literally every plugin is hard-coded to 127.0.0.1 as the WebSocket address. And the plugin has to be on the same computer as the application anyway.
The application (StreamDeck) is written in QT - would that have something to do with it?
Oh, regular TCP doesn’t work, it seems like I have to implement a WebSocket, btw… (Not sure how much of it, I’ll figure that out over the next while)
It all could be so much simpler if they just used regular TCP, it seems!
Because the client side (such an an HTMPViewer) is speaking HTTP on top on TCP, and the server is responding in kind. That is unsuited to general communication between two entities which are just interested in exchanging data, without any headers or other junk.
Further, AFAIK you can’t open a TCP socket in javascript, but you can open a websocket - the ability is built-in. As I said upthread, when you do that, there is first of all a very specific exchange between the sides where they agree to stop using HTTP and use websockets instead. That allows for a much more efficient subsequent data exchange.
You can read more about it here, including more stuff about what I’ve outlined:
I think that would be the reason. I didn’t know that. New to JS so still figuring this out.
Thank you.
The RFC was linked earlier. Just trying to see how to get away with the least amount of work. I could use someone else’s WS class, roll my own, or just stick with JS or some hybrid. Seems other languages have WS as part of their core, interesting that Xojo doesn’t.
Love to know how much I really need to implement of the WebSocket class if I’m just passing JSON packets back and forth. Obviously the handshake, but would all the rest need to be there? The Pings/Pongs, etc…
hard to know without a spec about how StreamDeck uses them and how much of the websocket protocol it expects to be present and usable
you could probably start by getting the initial handshake done trying it then seeing what else it expects