rpc - What could cause an active TCP close to return without notifying the passive end? -

i'm puzzled behavior of tcp-using application. when application @ 1 end of internet-wide tcp connection calls close() on socket, close() returns. @ other end, however, write() on socket doesn't indicate tcp connection closed. afaik, behavior inconsistent tcp specification: active close() shouldn't return unless , until receives acknowledgement other end of tcp connection (specifically, tcp state @ active end can't transition out of time_wait_1 unless receives appropriate response other end -- @ point write() @ other end should error-return).

i've seen behavior when malfunctioning intrusion prevention system (ips) between ends of tcp connection. manufacturer of ips addressing problem.

are there other situations in behavior can occur?

my environment unix, c, onc rpc, , sockets.

you conflating protocol state transitions , api behaviour. there nothing in rfcs says close() api can't return application , protocol actions proceed asynchronously, , happens in sockets api default. if there's pending data sent sitting in socket send buffer , receiver slow take arbitrary amount of time fin sent. can change setting linger timeout socket option so_linger, causes close block until data has been flushed or timeout expires, hardly ever used in practice.