Re: Keep state connections randomly dropped

hello,

> the idea is right...but perhaps a different change can be made
> so that this if() doesn't need to be so complex and the natural
> comparison holds true...

it's just a trade, make a change in one single place even it looks
complex (awful),
make it nice here and introduce more changes (bugs) elsewhere. one has
to decide.

> IPF_TCPS_SYN_SENT and the other is IPF_TCPS_LISTEN.
> or maybe that does make sense?

as far as I can understand it is the same state as SYN RECVD state
in TCP state machine. I've check sources quickly, It has turned out that
IPF_TCPS_LISTEN is not being used anywhere. I think it can be removed.

regards
sasha

2007/3/21, Darren Reed <darrenr@reed.wattle.id.au>:
> the idea is right...but perhaps a different change can be made
> so that this if() doesn't need to be so complex and the natural
> comparison holds true...
>
> I'm thinking of either chanigng _CLOSED to be 11 (and renumbering
> all of the other states, so that _LIStEN becomes 0) or adding a new
> one, IPF_TCPS_DELETE.
>
> The problem with making _CLOSED be 11 (rather than 0) and _LISTEN
> be 0, is that _LISTEN isn't technically correct (or maybe it is?), for state
> that has been created by the first SYN packet, so one side s
> IPF_TCPS_SYN_SENT and the other is IPF_TCPS_LISTEN.
> or maybe that does make sense?
>
> Darren
>
>