MiddlewareActor sits between the raw UDP socket and the "main" actors (either LoginActor or SessionActor) and handles crypto and control packets. The former side is called the outbound network (the clients); the former is called the inbound local (server). This service sets up cryptography, it decodes incoming packets, it encodes, bundles, or splits outgoing packets, and it handles things like requesting/resending lost packets. Accurate operation of the service is mostly a product of the network being agreeable and allowing packets to arrive correctly. Various subroutines are used to keep track of the predicted offending packets.

The cryptographic aspect of the service resolves itself first, exchanging keys and passcodes and challenges between local and the network. Most of this process occurs without any prior cryptographic setup, relying on the validation of its own exchange to operate. Afterwards its completion, all raw data arriving from the network or leaving to the network will require a cipher based on the previously exchanged data.
As packets arrive from local with the intention of being sent out towards the network terminus, they will be pooled into a buffer. Periodically, the buffer contents will be evaluated, and packet data of enough quantity and combined length will be assembled into a singular packet bundle. This bundle will be queued and dispatched towards the network. If the outbound packets do not arrive at the network terminus correctly, the network has a method of dispatching requests for identified missing packets. This side of the communication will keep track of its previously dispatched packets for a "reasonable" amount of time and will respond to those requests if possible by searching its catalog.

If the inbound packets do not arrive correctly the first time, after a while, requests for identified missing packets from the network source will occur. Virtually all important packets have a sequence number that bestows on each packet an absolute delivery order. Bundled packets have a subslot number that indicates the total number of subslot packets dispatched to this client as well as the order in which the packets should have been received. If a packet is out of sequence - a future packet, compared to what is being expected - it is buffered. Should the expected packets show up out of order before the buffered is cleared, everything sorts itself out. Unresolved missing sequence entries will often lead to requests for missing packets with anticipated subslots. If these requests do not resolve, there is unfortunately not much that can be done except grin and bear with it.