Waterpoint MCP listener

The problem

The Waterpoint MCP listener exists because of TWin. TWin is pretty cool. The problem arose because, before the MCP listener, in order to use TWin you had to use the TWin client as your primary MUD client. It is not a great primary MUD client. We wanted a way to allow users to use the TWin client to augment the capabilities of their primary MUD client.

The solution, such as it is

The MCP listener port is a secondary listening port (3969) separate from the primary port. It is intended for clients that implement MCP packages not implemented by the user's primary client. When a client connects to port 3969, the MCP 2.1 negotiation process begins immediately (before authentication). This is to allow an MCP package to handle the authentication, though the standard 'connect player password' form of authentication also works. The only package this is implemented for is the twin-window package, to allow a TWin client to authenticate using a TWin form and not need to pop up a MUD interaction window.

Once a connection is authenticated, the 'secondary' MCP session is made available to MUD applications querying for supported packages on the user's player. A few allowances are required by the server-side MCP package to support being used in this way but they are relatively minor and have already been done for the cords support. MCP packages written with this in mind work for both "primary" connections and "secondary" connections.

A package chooses the connection to handle its messages by using the first connection of (primary, secondary connections in the order they connected) that supports the package. At this time, the desired version of a package does not play a role in selection nor is there any way to affect the order of selection, nor is there really any interface for the primary connection to manage the secondary connections (e.g. if you're connected from the office and reconnect from home on the primary connection).

On the whole, this is sort of backwards from the way MCP was intended (a way to multiplex OOB messages and interaction), but it was the only solution that was both quick to get a hacky version implemented (and thus quick results: being able to use the TWin client with jmud) and did not require any changes to the "primary" client.

The future, if any

Obvious future enhancements to this mess include providing some UI for managing the secondary connections, providing some control over which connection is used for which package, modifying the negotiation sequence so later secondary connections do not get offered packages that are already being handled by earlier connections (perhaps), etc.