WebSocket transport beside TCP, same RF session

The gameserver already runs login, character select, and the world on one socket, and the wire package for each family frames, ciphers, and decodes those bytes. Please give that same session a second way in: a WebSocket listener, so a browser client can play on the same world as the native RF client.

A page in a browser cannot open the TCP port RF_Online.bin uses. It can open a WebSocket. If that socket delivers the same framed bytes the existing codec already understands, the web client is another peer of the same accounts, characters, and world.

What this is:

• A WebSocket listener on the gameserver, off unless the operator turns it on. With it off, the server is the one you ship today. • Binary frames. Each frame is one message the current codec already handles, length and opcode included, passed through the same cipher the TCP path uses. No second protocol and no WebSocket variant of the structs. • The accept path hands the connection to the same session code the TCP accept path uses. One player, one character online, on either transport. A second login replaces the first the way it already does. • The original client keeps the TCP port and never sees this listener. Byte-for-byte with that client stays the rule, and games/*wire stays per family. • Each gameserver is already one game, so the listener does not choose a protocol. A subprotocol named for the build is enough for a mismatched client to fail at the handshake instead of on the first packet. • WebSocket ping/pong keeps the socket alive through proxies and stays outside the game codec. • The website you already ship can terminate wss and proxy the socket, so the game port can stay private. Operators who only run the native client open nothing new.

This belongs in the framework rather than in one RF version. The protocol layer is already separate from the socket, so a second transport there reaches every game the next time that game ships. RF is the one I want it for. A web client can then sit next to the GameCP, on the same accounts, without a second world and without a desktop client in the middle.

I am not asking you to write or support that client. The Automation API drives GoMMO Client over MCP or HTTP. This is the other direction: a client that speaks to the gameserver itself, the way RF_Online.bin does, over the only transport a browser has.