Signal handling is closely tied to our implementation of sockets, which is described in the next section.<\/li>\n<\/ul>\n\nThe list of servers within the game and on the homepage<\/i><\/p>\nSocket Implementation<\/h1>\n
\nWe want to create an API that is as close to Posix UDP Sockets as possible to minimize the necessary changes.<\/p>\n
We also want to implement the bare minimum required for the simplest data exchange over the network.<\/p>\n
For example, we do not need true routing: all peers exist in a single 'virtual LAN' connected to a specific instance of the Firebase database.<\/p>\n
Therefore, we do not need unique IP addresses: to uniquely identify peers, it's sufficient to use unique Firebase key values (similar to domain names), and each peer locally assigns 'fake' IP addresses to each key that needs to be transformed. This completely eliminates the need for global IP address assignments, which is a non-trivial task.<\/p>\n
Here is the minimal API that we need to implement:<\/p>\n
\/\/ Create and destroy a socket\nint socket();\nint close(int fd);\n\/\/ Bind a socket to a port, and publish it on Firebase\nint bind(int fd, AddrInfo* addr);\n\/\/ Send a packet. This lazily create a WebRTC connection to the \n\/\/ peer when necessary\nint sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);\n\/\/ Receive the packets destined to this socket\nint recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);\n\/\/ Be notified when new packets arrived\nint recvCallback(Callback cb);\n\/\/ Obtain a local ip address for this peer key\nuint32_t resolve(client::String* key);\n\/\/ Get the peer key for this ip\nString* reverseResolve(uint32_t addr);\n\/\/ Get the local peer key\nString* local_key();\n\/\/ Initialize the library with the given Firebase database and \n\/\/ WebRTc connection options\nvoid init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);<\/code><\/pre>\n\nThe API is simple and resembles the Posix Sockets API, but has several important differences: callback registration, local IP assignment, and 'lazy' connection<\/strong>.<\/p>\nCallback Registration<\/h2>\n \nEven if the original program uses non-blocking I\/O, the code needs to be refactored to run in a web browser.<\/p>\n
The reason for this is that the event loop in the browser is hidden from the program (whether it\u2019s JavaScript or WebAssembly).<\/p>\n
In a native environment, we can write code like this<\/p>\n
while(running) {\n select(...); \/\/ wait for I\/O events\n while(true) {\n int r = readfrom(...); \/\/ try to read\n if (r < 0 && errno == EWOULDBLOCK) \/\/ no more data available\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nIf the event loop is hidden from us, we need to turn it into something like this:<\/p>\n
auto cb = []() { \/\/ this will be called when new data is available\n while(true) {\n int r = readfrom(...); \/\/ try to read\n if (r < 0 && errno == EWOULDBLOCK) \/\/ no more data available\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ register the callback<\/code><\/pre>\n<\/p>\n
Purpose of local IPs<\/h2>\n \nNode identifiers in our 'network' are not IP addresses, but Firebase keys (these are strings that look like: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nThis is convenient because we don\u2019t need a mechanism to assign IPs and check their uniqueness (as well as their recycling after a client disconnects), but it is often necessary to identify peers by numerical value.<\/p>\n
This is exactly what the functions resolve<\/code> and reverseResolve<\/code>: the application somehow obtains the string value of the key (through user input or through a master server), and can convert it into an IP address for internal use. The rest of the API also receives this value instead of the string for simplicity.<\/p>\nThis is similar to a DNS lookup, except it is performed locally by the client.<\/p>\n
That is, IP addresses cannot be shared among different clients, and if a global identifier is needed, it must be generated in another way.<\/p>\n
Lazy connection<\/h2>\n \nUDP does not require a connection, but as we have seen, before starting to transfer data between two peers, WebRTC requires a lengthy connection process.<\/p>\n
If we want to provide the same level of abstraction, (sendto<\/code>\/recvfrom<\/code> with arbitrary peers without prior connection), we must perform 'lazy' (deferred) connection within the API.<\/p>\nHere\u2019s what happens during a standard data exchange between a 'server' and a 'client' when using UDP, and what our library needs to perform:<\/p>\n
\nThe server calls bind()<\/code>, to inform the operating system that it wants to receive packets on a specified port.<\/li>\n<\/ul>\n\nInstead, we will publish the open port in Firebase under the server key and listen for events in its subtree.<\/p>\n
\nThe server calls recvfrom()<\/code>, receiving packets sent from any host to this port.<\/li>\n<\/ul>\n\nIn our case, we need to check the incoming packet queue sent to this port.<\/p>\n
Each port has its own queue, and we add the source and destination ports to the beginning of WebRTC datagrams so we know which queue to redirect a new packet to upon arrival.<\/p>\n
The call is non-blocking, so if there are no packets, we simply return -1 and set errno=EWOULDBLOCK<\/code>.<\/p>\n\nThe client obtains the server's IP and port by some external means and calls sendto()<\/code>. An internal call is also made at this point, so the subsequent bind()<\/code>request proceeds. recvfrom()<\/code> will receive a response without explicit binding execution.<\/li>\n<\/ul>\n\nIn our case, the client externally obtains a string key and uses the function resolve()<\/code> to obtain the IP address.<\/p>\nAt this stage, we initiate the WebRTC handshake if the two peers are not yet connected to each other. Connections to different ports of a single peer use the same WebRTC DataChannel.<\/p>\n
We also perform an indirect bind()<\/code>, so that the server can restore the connection in the next sendto()<\/code> in case it was closed for any reason.<\/p>\nThe server is notified of the client's connection when the client records its SDP offer under the server port information in Firebase, and the server responds there with its own response.<\/p>\n
\nThe diagram below shows an example of message flow for the socket scheme and the transmission of the first message from the client to the server:<\/p>\n
The complete connection stage scheme between the client and the server.<\/i><\/p>\nConclusion<\/h1>\n
\nIf you have read this far, you are probably interested in seeing the theory in action. You can play the game on teeworlds.leaningtech.com<\/a><\/noindex>, give it a try!<\/p>\n