Comment by tracker1
16 days ago
Serious question, why not just use websockets? AFAIK, it's effectively a TLS socket with a little bit of handshake overhead when starting.
I'm literally working on a web interface I want to use for classic BBS door play... currently working on a DOS era EGA interface, and intend to do similar for PETSCII/Comodore64/128 play as well. I've got a couple rendering bugs to explore for ansis submitted that messed up in the viewer test mode.
https://github.com/bbs-land/webterm-dos-ansi
It's been an opportunity to play with AI dev as well... spent as much time getting the scrollback working how I want as it took on the general rendering.
Websockets is just another layer on top of TLS, so you've got the size explosion and complexity/latency of TLS and then another layer on top of that. The OP hasn't provided additional info on what the requirements are but if it's a realtime game then they'll probably be "as close to zero latency and size increase as possible (compared to unencrypted messaging)", which websockets over TLS isn't.
Unless I'm completely misunderstanding, once you "upgrade" the connection to a websocket connection, it's pretty much a bog standard TLS socket... I'm not sure what you mean by a size explosion, compared to what? As to latency or overhead, yeah there's some, but generally very minimal on anything resembling modern hardware, there are literally trillions of bytes transported over HTTPS/TLS every day from watches to super computers.
Beyond this, there are libraries and tunnels for everything under the sun, and it's one of the least likely options to see mass breakages in general given it handshakes over 443 (https). Assuming you want encryption... if you don't then use raw sockets, or websockets without https and/or raw sockets... You can use whatever you like.