evennia: Autoconnects in Atlantis client don't work for Evennia

Brief summary of issue / Description of requested feature:

Evennia doesn’t seem to play well with the autoconnect feature on the Atlantis client, requiring typing out the connection command every time.

Steps to reproduce the issue / Reasons for adding feature:

  1. Save a world in Atlantis’s address book with character login details.
  2. Connect to Evennia.
  3. Get feedback instead of logging in automatically.

Error output / Expected result of feature

Auto-connection attempts are often spit back as if they were preceded by a mess of characters, such as: Command 'ÿûcon Character Password' is not available. Type "help" for help.

Or even as much mess as: Command 'ÿûÿú�j�%ÿðÿûÿýVÿþFÿþEÿþÉÿþ[connect Character Password' is not available. Type "help" for help.

Extra information, such as Evennia revision/repo/branch, operating system and ideas for how to solve / implement:

@packetdancer, the creator of Atlantis, can probably help with this. I know she was poking at things on her end, and I’m sure she’d be happy to share Atlantis files.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 42 (41 by maintainers)

Commits related to this issue

Most upvoted comments

Excellent, thanks yourself (and the others in this thread) for all the help!

Looking more at this, I think there could be some considerable cleanup in the telnet protocol to better make use of Twisted’s functionality. That goes beyond a simple patch though; I’ll look into this in the next few days.

@packetdancer, @TehomCD: To test this, I created the most slimline and fast telnet client imaginable: It connects to a game and immediately on connection sends the “connect name password” string and prints what it gets back.

In testing I do see garbled text returned, this is due to Evennia immediately sending the telnet negotiation upon connection (which my dummy client of course can’t handle). This is expected behavior, it’s the handshake telling the client what the server supports and asking the client to report its status. After seeing this string however, Evennia then correctly logs me in, so even with this extremely fast login I cannot reproduce the issue.

Translated to numbers, this is the telnet handshake Evennia sends (adding spaces for readability):

255 253 31 255 253 24 255 251 86 255 251 70 255 251 69 255 251 201 255 251 91

Which means

IAC DO NAWS      # ask client to report its window size
IAC DO TTYPE     # ask client to identify itself and its capabilities
IAC WILL MCCP    # server offers stream compression if client wants it
IAC WILL MSSP    # server offers to report its status to a Mud listing if client wants it
IAC WILL MSDP    # server offers out-of-band MSDP data services if client wants it
IAC WILL GMCP    # server offers out-of-band GMCP data services if client wants it
IAC WILL MXP     # server offers MUD extensions (clickable links) if client wants it

I have run the speed-connect dummy client both locally, against the Evennia demo server and against Arx (logging in as guest). In all cases I login correctly. My simple dummy client of course just prints the initial telnet negotiation string. I suspect Atlantis should not be printing IAC-prefixed instructions to the output regardless of when it arrives, but I don’t recall exactly how the protocol looks on the client side.

At this point I don’t know if it’s much more I can do to test this - Evennia behaves as expected (according to the standard specification) and is actually very fast about it. I don’t know if a MUSH server is just slower or deliberately delays the handshake but as far as Evennia is concerned, everything appears to react and be processed at max speed; with this simple client the entire login and authentication process happens in about a tenth of a second or so (1/2 a second remotely on Arx).

As far as I know, neither the telnet client nor the -server are dictated by the protocol to await the completion of the telnet handshake before allowing data transfer. Could maybe Atlantis be expecting a delay upon connect that it doesn’t see with Evennia? If this could be shown to be the case we could delay things on the Evennia side I guess, but it would have to be a general synthetic slowdown since this all happens long before the TTYPE negotiation has completed and Evennia knows which client has connected.

The reason for this is not clear, but sounds likely to be due to timing. Evennia’s telnet connection happens at Evennia’s Portal layer, which then needs to inform the Server about the new connection. But several MUD-specific telnet negotiations like TTYPE requires several exchanges between the server and portal (their speed depending on the network connection) meaning the Portal will update the session again when it has all the (potentially delayed) info. While this sync is normally very fast, the timing may vary depending on the hardware. The automatic login sending data faster than the sync can happen should normally be fine - the data should be queued. Maybe there is something going wrong in that queuing mechanism for this particular state of the connection, definitely worth looking into.

@Packetdancer Thanks for looking into this as well, always good to see active client devs around!