Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Basically the same as SOCK_DGRAM works except that send() and recv() expect/provide the TCP header before the transport payload.

If a user process calls bind() on some address/port then it gets all TCP packets for that local address/port. If it calls connect() then it gets only the ones that match both the local and remote address/port.



With packet retransmissions and out-of-order packet delivery, wouldn't there be a risk that the client software at uid=10 sees a clean shutdown and disconnects, but uid=20 instantly binds with the same ports and steals a bunch of delayed packets?


That happens with UDP already and is another reason everything ought to be encrypted with session keys.

But the normal TCP solution of the OS holding released ports in TIME_WAIT for a couple of minutes still works as ever.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: