From owner-freebsd-net Tue Jun 26 12:26:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-d01.mx.aol.com (imo-d01.mx.aol.com [205.188.157.33]) by hub.freebsd.org (Postfix) with ESMTP id 6AA7C37B401 for ; Tue, 26 Jun 2001 12:26:31 -0700 (PDT) (envelope-from FastPathNow@netscape.net) Received: from FastPathNow@netscape.net by imo-d01.mx.aol.com (mail_out_v31.6.) id x.3.195f340 (16232); Tue, 26 Jun 2001 15:25:51 -0400 (EDT) Received: from netscape.com (aimmail10.aim.aol.com [205.188.144.202]) by air-in02.mx.aol.com (v78_r3.8) with ESMTP; Tue, 26 Jun 2001 15:25:51 -0400 Date: Tue, 26 Jun 2001 15:25:51 -0400 From: FastPathNow@netscape.net To: luigi@info.iet.unipi.it Cc: FastPathNow@netscape.net, freebsd-net@freebsd.org Subject: Re: TCPS_HAVERCVDFIN not considering all possible conditions? Mime-Version: 1.0 Message-ID: <1DEC8D97.1B5FD06C.375A6AF3@netscape.net> References: <200106261837.UAA98582@info.iet.unipi.it> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > be possible to do interesting things things like state tracking > > for individal connections, such that every time we move into the > > next state instead of doing something like tp->t_state = TCPS_SYN_RCVD, > > we can have something like tp->t_state |= TCPS_SYN_RCVD . The only > > useful purpose that I can think of would be have a history of the > > past states in the t_state variable. > > > Even without this ORing change, it would still make writing macros such as the above easier > > No way! that would be even more wrong. > > One state is one bit, and state changes are strict assignments. > The bit-set only makes it more efficient to test for set membership > ( "state \in {S1, S2, S3 ...}" becomes ( tp->t_state & (S1|S2|S3) != 0 ) > >     cheers >     luigi When I mentioned the ORing change, I was implying that other portions of the code would also have to be in sync with this change. As in -- a simple switch statement like the follows will not be sufficient: switch(tp->t_state) { case TCPS_SYN_RCVD: } As far as every possible succeeding state for a connection that is part of the FSM is denoted by a higher bit, the highest set bit in the t_state variable will always have the current state of the connection. The exception to this is .. when you move into TCPS_CLOSED state, clear out all bits. So the states would look something like: #define TCPS_CLOSED 0 /* closed */ #define TCPS_LISTEN 1 /* listening for connection */ #define TCPS_SYN_SENT 2 /* active, have sent syn */ #define TCPS_SYN_RECEIVED 4 /* have send and received syn */ /* states < TCPS_ESTABLISHED are those where connections not established */ #define TCPS_ESTABLISHED 8 /* established */ ... So switch based code fragments such as the above can be modified to switch(HIGHEST_SET_BIT(tp->t_state)) { case TCPS_SYN_RCVD: } Maybe I am missing something here, but theoretically wouldnt such a scheme work?. With this sort of a bit masking scheme the check that you make would still be valid because each state by itself is uniquely identified by its own bit position. Regards -AG __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message