1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
Three pieces of state need to be kept for each side of each option.
(You need the localside, sending WILL/WONT & receiving DO/DONT, and
the remoteside, sending DO/DONT and receiving WILL/WONT)
MY_STATE: What state am I in?
WANT_STATE: What state do I want?
WANT_RESP: How many requests have I initiated?
Default values:
MY_STATE = WANT_STATE = DONT
WANT_RESP = 0
The local setup will change based on the state of the Telnet
variables. When we are the originator, we can either make the
local setup changes at option request time (in which case if
the option is denied we need to change things back) or when
the option is acknowledged.
To initiate a switch to NEW_STATE:
if ((WANT_RESP == 0 && NEW_STATE == MY_STATE) ||
WANT_STATE == NEW_STATE) {
do nothing;
} else {
/*
* This is where the logic goes to change the local setup
* if we are doing so at request initiation
*/
WANT_STATE = NEW_STATE;
send NEW_STATE;
WANT_RESP += 1;
}
When receiving NEW_STATE:
if (WANT_RESP) {
--WANT_RESP;
if (WANT_RESP && (NEW_STATE == MY_STATE))
--WANT_RESP;
}
if (WANT_RESP == 0) {
if (NEW_STATE != WANT_STATE) {
/*
* This is where the logic goes to decide if it is ok
* to switch to NEW_STATE, and if so, do any necessary
* local setup changes.
*/
if (ok_to_switch_to NEW_STATE)
WANT_STATE = NEW_STATE;
else
WANT_RESP++;
* if (MY_STATE != WANT_STATE)
reply with WANT_STATE;
} else {
/*
* This is where the logic goes to change the local setup
* if we are doing so at request acknowledgment
*/
}
}
MY_STATE = NEW_STATE;
* This if() line is not needed, it should be ok to always do the
"reply with WANT_STATE". With the if() line, asking to turn on
an option that the other side doesn't understand is:
Send DO option
Recv WONT option
Without the if() line, it is:
Send DO option
Recv WONT option
Send DONT option
If the other side does not expect to receive the latter case,
but generates the latter case, then there is a potential for
option negotiation loops. An implementation that does not expect
to get the second case should not generate it, an implementation
that does expect to get it may or may not generate it, and things
will still work. Being conservative in what we send, we have the
if() statement in, but we expect the other side to generate the
last response.
|
