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
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.
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
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.
Yes I could send you the WebSocket class and the Server thread and some notes I’ve made.
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.
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.
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.
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