Yes, they're still necessary for a number of reasons, all of them based on the observation that TCP gives reliability between the ends but not at the ends themselves.
First, TCP will notice the absence of an endpoint only when the other endpoint has unacknowledged data; eventually the timeout-and-retry mechanism exhausts itself and initiates a connection reset. However, the timeout-and-retry mechanism can take a while to initiate a reset, and an application wanting timely notifications needs to provide for itself.
Second, if the connection has no unacknowledged data and is quiescent, TCP is under no obligation to discover endpoint loss. This situation is similar to the case when a client makes an expensive request to a server; the request is acknowledged, leaving no unacknowledged data in the connection, and the sever goes off for a long time to satisfy the request. The client is responsible for distinguishing between long service time and a dead server.
Third, if the TCP API provides facilities for detecting endpoint loss during quiescent periods, as does the Sockets interface, the characteristics of the notification may not be suitable for a particular application, especially with respect to the delay between endpoint loss and notification.
The principle restriction is placed by limits on the amount of system resources available for representing concurrently active computations. The main resource limit is probably the number of open TCP connections available; storage limits are another possible, but less probable, source of restrictions (a system with limited storage is also likely to limit open TCP connections too because each connection requires a significant amount of storage).
It's only true if the sequence of writes are done atomically; that is, without being interspersed with writes from other clients. Even co-incident writes may not be a problem if they write non-overlapping parts the file.
The main tread would begin handling a request and, if not completed after some pre-determined period of time, would hand off the request to a subsidiary thread for completion. The advantage to delayed allocation is less overhead: the pre-allocated threads are ready to go and don't need to be created on demand as done in pure delayed allocation. The disadvantage to pre-allocation is the complexity of picking up a request in the middle of it being processed; this is harder than starting with the request and carrying it through to completion.
This page last modified on 13 April 2001.