This is my raw multiplayer/matchmaking engine, which does not function on the usual player slot method. Look at notes for an overview of the engine design. If handshakes are timing out quickly, it is most likely trying to connect to ghost player (ie. remnants of previous conversations in the channels). Test by opening multiple tabs. For a tangible demonstration, see my multiplayer chess game at https://scratch.mit.edu/projects/478209374
Before you claim this is fake, make sure you are a full Scratcher and test it by opening multiple tabs. You can play yourself in this way. This multiplayer engine utilizes an address-based system instead of the typical player-slot method. This allows for far more than ten players to be on the network at the same time. As a trade-off, it is really only useful for turn-based games, as real-time games will quickly overload the channels with unconfirmed messages. In addition, message bandwidth is capped at 9000000 (with the rest taken up by metadata), and messages exceeding this limit will be dropped (or in rare cases cause cross-game interference). Engine functions by sending messages across randomly chosen channels in a message/iterator/sender/recipient format. These channels are constantly checked for messages addressed to you or for all-network pings. Because this system opens up the possibility of messages overwriting each other, each message has to be confirmed by the recipient to ensure reliability. If a message is not confirmed in time, it is resent. If a message times out 5 times, it is finally dropped (this is almost always due to the recipient no longer being there). A client program can send messages by adding the message to the SEND list and the recipient to the TO list. Incoming messages will appear in the MESSAGES list and their senders in the FROM list. The engine takes care of the rest. Matchmaking works on a ping-query system in which each searching player semi-randomly alternates between "ping" and "query" states. Pinging players repeatedly send out all-network pings and await queries. Querying players respond to pings with query messages. When a pinger receives a query, they respond with a shake. When the querying player receives this shake, they confirm it and are done matchmaking. When the pinging player receives this confirmation, they are done matchmaking. For a more in-depth description of how each part functions, look at the in-code comments on each function.
