Code Refactoring Opportunities

[dsriseah]

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.

[dsriseah]

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 of pkt.IsReq(), which would be better to use, and would allow compound conditions like isForwardedPacket() and isReturningPacket() and isFowardedPacketResponse()
• [X] Remove dead code, conform names, parts of speech, operational verbs

Resolved as part of ursys-auth 3fd499416