RE: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

["Anantha Ramaiah (ananth)" <[e-mail]>]

 
> 
> > So implementations can chose
> > to have some optimal schemes built inside TCP module on 
> behalf of the 
> > applications ( it is just a matter of 
> programming/implementation) and 
> > have an implicit timer inside TCP which kills the TCP 
> connection when 
> > timer expires and can inform the application about the 
> connection death.
> 
> That timer would need to have a default of "infinite" - i.e., 
> it would default to never going off - to be compliant with 
> RFC1122. Only if the application instructed it otherwise 
> could it activate.
> 
> Putting the timer inside TCP does nothing useful at that 
> point except complicate TCP. The timer can be in the OS or in 
> the application with exactly the same effect.

That is your viewpoint, I can list the advantages of why putting the
timer inside TCP works for me. It may add some extra code to TCP but
make the application(s) life easier. 
 
> 
> > [All the above actions are compliant to the RFC since RFC 
> doesn't talk 
> > about how to implement TCP and it just gives a guidance, the term 
> > user/application and TCP are just used to illustrate the concept.]
> 
> If the timer defaults to "infinite", then yes, it would be 
> compliant with RFC1122. That doesn't change current behavior, though.

Yes, needless to say the timer would be initialised to infinity OR the
timer would never be started unless it is programmed to do so.

So, I think we are in agreement here that it doesn't matter from which
context you are aborting the TCP connection which is hanging in the
persist state. Any abort is compliant with the RFC. 

-Anantha


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm