I have studied accept() many times but still unfamiliar.
Useful as zbs, and perhaps QQ, rarely for GTD…
Based on P95-97 [[tcp/ip socket in C]]
- (probably) used in tcp only
- (probably) used on server side only
- usually called inside an endless loop
- blocks most of the time, when there’s no incoming new connections. The existing clients don’t bother us as they communicate with the “child” sockets independently. The accept() “show” starts only upon a new incoming connection
- thread remains blocked, starting from receiving the incoming until a newborn socket is fully Established.
- at that juncture the new remote client is probably connected to the newborn socket, so the “parent thread” have the opportunity/license to let-go and
return from accept()
- now, parent thread has the newborn socket, it needs to pass it to a child thread/process
- after that, parent thread can go back into another blocking accept()
- new born or other child sockets all share the same local port, not some random high port! Until now I still find this unbelievable. https://stackoverflow.com/questions/489036/how-does-the-socket-api-accept-function-work confirms it.
- On a host with a single IP, 2 sister sockets would share the same local ip too, but luckily each socket structure has at least 4  identifier keys — local ip:port / remote ip:port. So our 2 sister sockets are never identical twins.
-  I omitted a 5th key — protocol as it’s a distraction from the key point.
-  2 variations — parent Thread or parent Process.