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

MURALI BASHYAM wrote:
...
>>
>> MURALI BASHYAM wrote:
>> ...
>>> The issue here is that TCP cannot inform the application and have the
>>> application initiate the abort, because it is  not necessary that
>>> the application has that connection state around anymore, it
>>> could have been destroyed already, i've alluded to this issue
>>> before.
>> 
>> And I have already shown how to address it - SO_LINGER.
>> 
>> In the case of a Unix close() call, this can be used to cause 
>> close() to block until either the graceful shutdown completes
>> (i.e., all data is sent and ack'd, and the other end closes) OR a
>> timer expires.
>>
>> SO_LINGER already supports a timer for this purpose.
>>
>> Can we please stop trying to add to TCP that which ***ALREADY*** exists
>> in the implementation?
> 
> Turning SO_LINGER on causes the application to pay a penalty in the normal
> scenario, where the close call will block even with a legitimate receiver (or a slow
> network). This is precisely why applications do not use it, it ties up resources 
> unnecessarily, and how about applications that want non-blocking semantics?. High
> performance applications care about non-blocking semantics.

Modern applications programmers are aware of multithreading.

You can either leave the app around watching the connection, or offload
that to a socket library - i.e., a SOCKET timer (note - note a protocol
timer).

> Let's stop recommending to applications how to use the 
> socket layer, we have to approach this in a manner that doesn't question or change
> their socket layer usage model.

But you want to change their protocol interface model instead?

> Application changes should be incremental and not
> disruptive, that's the idea of doing this in the transport layer in the first place.

Applications should have changed long ago. Some definitely need to catch
up. There is no way to handle DOS attacks with legacy applications
written in a legacy manner.

Joe

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

Attachment: signature.asc