Add WebSocket client LogiX node

[TylorShine]

I want to use the WebSocket to communicate local (and external) server from/to the Neos.
For example (I want to),
[MIDI Instrument]->[PC]->[Local WebSocket server]<->[NeosVR LogiX node in world]->[Trigger particles by MIDI Instrument signal "real-time, continuously"]
etc...
Currently Neos has HTTP POST/GET LogiX node already, but it is not enough real-time (little bit delaying) and many overhead for continuously data communication purpose.
If necessary, I upload Neos extra library source code to use WebSocket to GitHub. Please kindly, consider this.

I joined Neos a few days ago, I'm surprised that Neos' versatility. It's a great "Metaverse" platform!
We're grateful to you!!!

[Frooxius]

WebSocket has been requested a few times in the past and is definitely on the list of things to be added. There are however two main problems that need to be considered first:

• Security. We should not let anyone connect to any WebSocket without asking the user for permission first. I think for now the same model as for HTTP requests could be considered.

• API - how is the websocket actually used? How are data passed to it? As some high level structure/protocol? As raw stream of bytes that's serialized/produced by other nodes? How is the websocket itself represented? A single node that allows establishing connection and then sending data (using other nodes to handle things like serialization to bytes).

Similarly how are data received? As stream of bytes? Or by chunks as they arrive?

[sinni800]

I would suggest to be opinionated on the stream vs chunks etc front. I think most if not all Websocket servers that are supposed to interact with Neos will be built FOR Neos and with Neos in mind.

This means that I would actually suggest just going for the "message"-based abstraction rather than exposing frames (chunks, streams) to LogiX.

A message in a Websocket can be either binary or textual (the message header has a flag for that). A message consists of a variable amount of frames, a message does not have a header, each frame has a bit that indicates if it's the final frame of a message. A frame is not like an UDP datagram or anything, it's actually variable size, the size being encoded in the frame's header.

This means of course that a variable amount of variable frames make up a message, which means you should have a generous but not dangerous maximum message size, too.

An API would also become a lot less complicated if all you do is receive full messages and send out full messages.

[Frooxius]

Yeah that's what I was thinking, it would make it a lot easier to work with if it's all done in full contained "chunks", rather than having some way of having to maintain the stream state with LogiX. It will fit into the existing paradigms easier as well.

For the text vs. binary I'll have to see how to best expose this. Using binary is a bit more tricky, because we don't have collection support yet, so it's harder to compose a raw binary message to send. That will come later though.

[sinni800]

This is also incidentally the most common way of using Websockets, by using the Websocket-built-in "messages" abstraction and sending textual messages back and forth. If people want complex data, they usually just send JSON as a text message

Few really bother with using binary messages unless they have some special need

[Frooxius]

Ah that makes sense. Strings can definitely be easier to work with! Coming from Neos I'm always thinking in terms of binary x3

I think I could expose a way to simply pass a string and send messages like that for now and add the binary support later. But I'll have to think what's the best way to expose that interface. Probably have a node that represents the socket and then other nodes that execute actions on this (send binary message, send text message and such)

[qdot]

+1'ing this. I just started in Neos like, 2 days ago, but having stateful connections versus having to run over HTTP GET/POST when doing LogiX work would be super helpful.

Agreed on just using text messages too. Trying to form something useful for binary like msgpack or protobuf in LogiX seems like it'd be... difficult.

[Frooxius]

I think binary is still crucial long-term, because you could be passing more heavy stuff like audio or image data, which isn't too practical to encode as string. However that'll be a later addition along with nodes to work with these more easily.

[Earthmark]

You need to route it through a text safe encoding, but protobuf isn't too bad through logix, dunno about message pack but I believe it's a somewhat similar encoding methodology wise.

[AlexanderPavlenko]

Another use case which may contribute to immersion 😏 https://www.metafetish.com/2018/08/17/lets-teledildonics/

[qdot]

Another use case which may contribute to immersion 😏 https://www.metafetish.com/2018/08/17/lets-teledildonics/

... Why else do you think I showed up on this issue, eh? :)

[Earthmark]

Just as some quick feedback, I've become aware of some users using the twitch chat node to fake getting server sent events over a websocket by having a server fake part of the twitch event action... so people are working around this perceived hole in great and terrible ways.

I'll try to point people towards polling for now (cause it doesn't matter localhost wise although it's not great design) but just know some eccentric approaches to this issue are being grown out in the wilds.

[Frooxius]

Added WebSocket support in 2020.9.2.10!

• Added WebsocketClient component (under Network) which is responsible for handling connection to a websocket server at given URL -- This follows the same host access rules as the HTTP nodes and will require user to approve connection to a particular host
• Added LogiX nodes to interface with the WebsocketClient component (under Network/Websocket) (requested by @ontodistro, @cashmoney, TylorShine (GitHub), @qdot, @Earthmark and others): -- Websocket Connection Events - fires event when connection opens/closes -- Websocket Text Message Receiver - fires when a text message is received on a given client -- Websocket Text Message Sender - allows sending a text message through a WebsocketClient instance (must be connected!) -- Websocket Connect - allows to set the URL and Handling user of WebsocketClient, which will make given user connect to particular URL --- If URL is omitted, the current one is kept, if user is omitted local user is used
• Added IsLocalUser node (implemented by @Coffee | Programmer)