[Ambar-dev] Fw: Re: papaya 0.96 in GNU/Linux

[Pablo Ruiz Múzquiz]

éste es un mensaje acerca de Papaya 0.96. gtk-papaya.org

La versión para Windows funciona bastante bien salvo porque mi
traducción se ha visto destrozada porque los widgets de papaya
no aceptaba iso88591 (está arreglado ya en el CVS).

La versión para GNU/linux no tiene ese problema, pero comparte con la de
windows el hecho de no entender bien nunca el primer carácter que se le
envía.
Esto no es grave en sí, porque le das de nuevo y ya va, pero queda
feo....

La explicación de por qué ocurre esto me la ha dado la propia Catherine
Allen y tiene que ver con nuestra implementación del protocolo de
conexión.

Voy a reenviar los otros correos que he mantenido con esta chica.

Saludos

Aranarth

Mensaje reenviado:

Fecha: Mon, 27 May 2002 12:35:21 +0100 (BST)
De: Catherine Allen <address@hidden>
A: Pablo Ruiz Múzquiz <address@hidden>
Asunto: Re: papaya 0.96 in GNU/Linux


On Mon, 27 May 2002, Pablo Ruiz Múzquiz wrote:

> The first character entered just after connecting to a MUD (at least,
> Minë) doesn't work (same as windows version). After this, everything
> goes fine.

It looks like there were two bugs related to creating characters.  The 
first was the result of Spells.cpp grabbing anything starting with 'c'
and 
putting c15 hnumber before it.

The second bug is caused by a partial implementation of the telnet 
protocol at Minë.  Hopefully the following will explain things well:

Minë doesn't fully implement the telnet protocol and so when Papaya
sends 
it a telnet option: IAC DO SGA it doesn't process it (or skip over it).
And so when the next character 'c' (or 'r') arrives, Minë thinks it has 
received (in hexadecimal):

 FF  FD 03  63 0A
 IAC DO SGA c  \n

If you were to start Minë on port 23 and connect to it using standard
(unix) telnet you would notice the same problem.  (It has to be port 23
for the test as telnet does some tricks with other port numbers to get 
around broken telnet implementations usually seen on MUDs, exactly as 
you're seeing with Papaya and Minë. :))

The question that should be answered is "Does Minë implement telnet, or 
does it use TCP over IP?"  If it wants to be 100% compatible with any 
client that implements the telnet protocol it needs to have implemented 
the whole telnet protocol, including the option negotiation that causes
it 
to 'fail' at the moment.

  RFC 1123 section 3.2.1

     3.2.1  Option Negotiation: RFC-854, pp. 2-3

         Every Telnet implementation MUST include option negotiation and
         subnegotiation machinery [TELNET:2].

As far as I can tell, Papaya isn't breaking any rules by sending that 
option negotiation code, and Minë should either process it and return an

answer or skip over it such that the first character after the 
option code is what it processes for the login command.

So, two solutions. :)

 1) Minë's coder should implement a bit more of the telnet protocol,
even 
    if only to skip over any telnet codes received.  This will make it 
    work with all telnet clients, even if it's moved to port 23 at some 
    date.  Useful RFCs are 854 and 1123.  And possibly others.

 2) Papaya should add a workaround to cater for broken server 
    implementations, similar to how telnet does.  If it receives a
telnet 
    option code from the server it is allowed to send telnet codes to
the 
    server, but otherwise it isn't allowed to send any telnet codes.

Cath
-- 
address@hidden
http://www.lancs.ac.uk/~allenc/




-- 
[Pablo Ruiz Múzquiz]
alqua.com | eutherpe.org
elenya.net| hammo.org