[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ambar-dev] Fw: Re: papaya 0.96 in GNU/Linux
From: |
Pablo Ruiz Múzquiz |
Subject: |
[Ambar-dev] Fw: Re: papaya 0.96 in GNU/Linux |
Date: |
Tue, 28 May 2002 00:09:55 +0200 |
é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
- [Ambar-dev] Fw: Re: papaya 0.96 in GNU/Linux,
Pablo Ruiz Múzquiz <=