DPM TCP interface

[beauremus]

A TCP interface for DPM will allow for more reliable delivery.

[beauremus]

Service discovery is an unsolved problem for TCP DPM connections. Can acsys-proxy fill this role?

[rneswold]

I thought that acsys-proxy would round-robin to the available DPMs. Wouldn't that serve as the service discovery?

[rneswold]

The TCP port for DPM should be moved, though. 6802 should still be used for ACNET connections (for Javascript clients, for instance.)

[beauremus]

Round robin is a simple starting place but it's not as useful as service discovery. We may be able to simply multicast a service discovery message from acsys-proxy.

[beauremus]

I agree with choosing a new port.

[rneswold]

Round robin is a simple starting place but it's not as useful as service discovery.

Okay, round-robin is a naive form of service discovery. I think we're both thinking the proxy task (which we're both including when mentioning the host, acsys-proxy) will perform the service discovery. Several possible options:

• Multicast a message.
• Use the ACNET service discovery.
• Keep track of its own pool of possible DPM nodes. It knows the amount of traffic coming from each DPM so it can send new requests to the least loaded node.
• DPMs can announce themselves to the proxy periodically to get added to the pool. The announcement can include load information. DPMs which don't announce after a while or refuse connections get removed from the pool.

[rneswold]

Getting resolved in #32.