dsriseah
commented
6 months ago URNET.Endpoint Class
This is a complicated class that encapsulated the URNET message systems in a network technology-agnostic way. Conceptually, the Endpoint class is capable of sending and receiving URNET.NetPacket objects (messages) through URNET.NetSockets (connection objects with send(), close(), and onData() messages).
A challenge is that Endpoint can work both as a client or server endpoint. As a client endpoint, it connects to a gateway. As a server endpoint, it listens for connections and manages clients. The main processing logic is slightly different depending on how the Endpoint is invoked:
- receives a packet via it's onData() handler through _ingestServerMessage() or _ingestClientMessage()
- receives either a new packet as request or response
- initiates a packet through netCall, netSend, netSignal, or netPing
CLEANUP
- [X] Currently, the naming weaknesses is that the receive vs initiate method names are difficult to concern. Ideally they would be named such that it's clear that it's "handling a new message request", "forwarding a message response", "sending a new message request", or "returning a message response".
- [X] Complicating this is that some methods are shared between the client and server interfaces.
- [X] There is also the use of direct checks like
if (pkt.msg_type)instead ofpkt.IsReq(), which would be better to use, and would allow compound conditions likeisForwardedPacket()andisReturningPacket()andisFowardedPacketResponse() - [X] Remove dead code, conform names, parts of speech, operational verbs
Resolved as part of ursys-auth 3fd499416
This is a tracking issue to note what opportunities I see for clarifying convoluted modules. In each comment, I'll note any commits that address them.