Re: [MacPerl] Client-Server Problems

["Thomas R. Kimpton" <tkimpton@maned.com>]

>At 5:13 PM 98.03.09, Jon Jacob wrote:
>
>> I apologize if this is not specific to MacPerl, but I am stumped and
>> frustrated.  If someone can direct me to a good list for this question that
>> would be great.
>>
>> Chris Nandor sent me the above code to create a server that will accept
>> input.  I have that down and it works.  However, when I telnet to the port
>> (in my case 2345) I do not get the Connect! on the client-side.  In other
>> words, the Server does not appear to be printing to the client as it should
>> or the output to the buffer is being held.  Any ideas what is causing this?
>>
>
>
>Are you using NCSA telnet to connect to the server? If so, my experience
>may be some help for you. (if not, please just ignore :-)
>
>I myself once have written a simple server script like yours, run it on
>Macintosh, and tried to connect to it with NCSA telnet (2.6.1d3 J7). I met
>the same kind of problem. As far as I knew from experience (not from
>theory), the problem was caused by some extra header which NCSA would send
>to the server at the beginning of connection. Then my workaround was just
>to remove this telnet spelling. I'll show it embedding into your code
>(please note that this might be dependant on the different versions of NCSA
>telnet) :
>
[stuff deleted]

I didn't pick up on this problem at first glance, but, Takashi's
message jogged my memory.  It looks like Telnet is doing TELNET Option
Negotiation. You can decode this by looking in /usr/include/arpa/telnet.h
on your SunOS box (or a variant on whatever unix/linux box you have
available). When you connect to services that use TELNET option
negotiation for their control protocol, or similarly, clients that
use it, you'll receive this.

What it boils down to is a set of negotiations:
    FF - Interpret next char as command
    FD - Do this next char as option
    xx - option

    FF - Interpret next char as command
    FE - Don't do this next char as option
    xx - option

When you get the FFFDxx send back FFFCxx. If they send FFFExx
send FFFCxx.  This is telling the remote end to not use the option.

As well Telnet may be sending options that it is willing/not willing
to perform:
    FF - Interpret next char as command
    FC - I won't do this next char as option
    xx - option

    FF - Interpret next char as command
    FB - I will (I'm willing to) do this next char as option
    xx - option

When you get the FFFCxx send back FFFExx. If they send FFFBxx
send FFFExx.  This is telling the remote end to not use the option.

If you want to respond to certain options you'll need to read the
pertinent RFCs (don't know off-hand what they are, see
http://www.internic.net/ds/dspg1intdoc.html).  I think
simply sending a newline for every negotiation request will
also work, though I'm not sure.

Tom.

Tom Kimpton
--
Mrs. Bun: Have you got anything without spam?
Waitress: Well, there's spam egg sausage and spam, that's not got
much spam in it.
Mrs. Bun: I don't want any spam!



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch