Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #5466 > unrolled thread

Telnet Sequence Negotiation

Back to article view | Back to comp.programming

Contents

  Telnet Sequence Negotiation Michael Griffin <mrmisticismo@hotmail.com> - 2015-05-28 03:18 -0500
    Re: Telnet Sequence Negotiation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-05-28 21:30 -0700
      Re: Telnet Sequence Negotiation Michael Griffin <mrmisticismo@hotmail.com> - 2015-05-28 23:35 -0500
      Re: Telnet Sequence Negotiation Michael Griffin <mrmisticismo@hotmail.com> - 2015-05-28 23:35 -0500

#5466 — Telnet Sequence Negotiation

 > I'm thinking in particular after having said "IAC WILL <FOO>", and
 > receiving a "IAC DO <FOO>",  can I later sao "IAC WONT <FOO>" to stop
 > FOOing?  And when I do that, will I receive an acknowledgement?
 >
 > Another way to ask this is:
 > If I received a "IAC DO <FOO>" after a "IAC WILL <FOO>", the other side
 > has the ability to change its mind "IAC DON'T <FOO>".  When they do
 > that, should I reply with "IAC WON'T <FOO>", or just silently accept the
 > new state of affairs?
 >
 > I think I realized the answer: If I receive a command that changes my
 > state, then I should acknowledge with the new state.  Defensive
 > programming says I shouldn't expect an acknowledgement, but handle one
 > cleanly.
 >
 > If I disable an option changes my handling of the data stream, I
 > shouldn't disable the processing until the byte after the response of
 > IAC DON'T/WON'T.
 >

Lets see if this reply will post this time :)

https://support.microsoft.com/en-us/kb/231866  even through it's 
Microsoft, it has a very good layout of the negotiation sequences.

Scroll down to the middle of the page where the heading is:

Associated with each of the these commands are various possible responses:

Basically if you send a DO or DON'T and get a reply, then you should 
change the settings according to the response.

But you want to track responses sent, vs responses received.  you don't 
want an endless loop of you -> Them -> you -> them again.

If you send a query, get a response for that item, then cut it there.
If you receive query, reply back, then cut it there.

Mike
telnet://htc.zapto.org

[toc] | [next] | [standalone]

#5473

On 5/28/15 1:18 AM, Michael Griffin wrote:
>
>  > I'm thinking in particular after having said "IAC WILL <FOO>", and
>  > receiving a "IAC DO <FOO>",  can I later sao "IAC WONT <FOO>" to stop
>  > FOOing?  And when I do that, will I receive an acknowledgement?
>  >
>  > Another way to ask this is:
>  > If I received a "IAC DO <FOO>" after a "IAC WILL <FOO>", the other side
>  > has the ability to change its mind "IAC DON'T <FOO>".  When they do
>  > that, should I reply with "IAC WON'T <FOO>", or just silently accept the
>  > new state of affairs?
>  >
>  > I think I realized the answer: If I receive a command that changes my
>  > state, then I should acknowledge with the new state.  Defensive
>  > programming says I shouldn't expect an acknowledgement, but handle one
>  > cleanly.
>  >
>  > If I disable an option changes my handling of the data stream, I
>  > shouldn't disable the processing until the byte after the response of
>  > IAC DON'T/WON'T.
>  >
>
> Lets see if this reply will post this time :)
>
> https://support.microsoft.com/en-us/kb/231866  even through it's
> Microsoft, it has a very good layout of the negotiation sequences.
>
> Scroll down to the middle of the page where the heading is:
>
> Associated with each of the these commands are various possible responses:
>
> Basically if you send a DO or DON'T and get a reply, then you should
> change the settings according to the response.
>
> But you want to track responses sent, vs responses received.  you don't
> want an endless loop of you -> Them -> you -> them again.
>
> If you send a query, get a response for that item, then cut it there.
> If you receive query, reply back, then cut it there.
>

Yep, that's basically what I wrote.  Only and always send a message if 
you are trying to make the state change, or are acknowledging a state 
change.

[toc] | [prev] | [next] | [standalone]

#5474

On 5/28/2015 11:30 PM, Daniel Pitts wrote:
>>
>> Lets see if this reply will post this time :)
>>
>> https://support.microsoft.com/en-us/kb/231866  even through it's
>> Microsoft, it has a very good layout of the negotiation sequences.
>>
>> Scroll down to the middle of the page where the heading is:
>>
>> Associated with each of the these commands are various possible
>> responses:
>>
>> Basically if you send a DO or DON'T and get a reply, then you should
>> change the settings according to the response.
>>
>> But you want to track responses sent, vs responses received.  you don't
>> want an endless loop of you -> Them -> you -> them again.
>>
>> If you send a query, get a response for that item, then cut it there.
>> If you receive query, reply back, then cut it there.
>>
>
> Yep, that's basically what I wrote.  Only and always send a message if
> you are trying to make the state change, or are acknowledging a state
> change.
>

Perfect, then you should be all set.

[toc] | [prev] | [next] | [standalone]

#5475

On 5/28/2015 11:30 PM, Daniel Pitts wrote:

>> Lets see if this reply will post this time :)
>>
>> https://support.microsoft.com/en-us/kb/231866  even through it's
>> Microsoft, it has a very good layout of the negotiation sequences.
>>
>> Scroll down to the middle of the page where the heading is:
>>
>> Associated with each of the these commands are various possible
>> responses:
>>
>> Basically if you send a DO or DON'T and get a reply, then you should
>> change the settings according to the response.
>>
>> But you want to track responses sent, vs responses received.  you don't
>> want an endless loop of you -> Them -> you -> them again.
>>
>> If you send a query, get a response for that item, then cut it there.
>> If you receive query, reply back, then cut it there.
>>
>
> Yep, that's basically what I wrote.  Only and always send a message if
> you are trying to make the state change, or are acknowledging a state
> change.
>

Perfect, then you should be all set.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web