socket accept() key points often missed

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[2]” can let-go and return from accept()
    • now, this thread has the newborn socket, it needs to pass it to a child thread/process
    • after that, this 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!
  • 2 sister sockets may share the same local ip too, but luckily each socket structure has at least 4 [1] identifier keys — local ip:port / remote ip:port. So our 2 sister sockets are never identical twins.
  • [1] I omitted a 5th key — protocol as it’s a distraction from the key point.
  • [2] 2 variations — parent thread or parent process.

good article: epoll() illustrated n contrasted^q(SELECT)

Compared to select(), the newer linux system call epoll() is designed to be more performant.

Ticker Plant uses epoll. No select() at all. is a nice article with sample code of a TCP server.

  • main() function with an event loop
  • bind()
  • listen()
  • accept()

I think this toy program is more educational than a real-world epoll server with thousands of lines of code.

No sample client but I think a standard TCP client will do.

TCP client set-up steps #some details

Client-side is a 2-stepper (look at Wikipedia and [[python ref]], among many references)
1) [SC] socket()
2) [C] connect()

[SC = used on server and client sides]
[C=client-only. seldom/never used on server-side.]

Note UDP is connection-less but connect() can be used too — to set the default destination. See

Under TCP, The verb connect() means something quite different — “reach across and build connection”[1]. You see it when you telnet … Also, server-side don’t make outgoing connections, so this is used by TCP client only. When making connection, we often see error messages about server refusing connection, because no server is “accepting”.

[1] think of a foreign businessman traveling to China to build guanxi with local government officials.


multicast address ownership#eg exchanges shows a few hundred big companies including exchanges. For example, one exchange multicast address falls within the range to
Intercontinental Exchange, Inc.
It’s educational to compare with a unicast IP address. If you own such an unicast address, you can put it on a host and bind an http server to it. No one else can bind a server to that uncast address. Any client connecting to that IP will hit your host.

As owner of a multicast address, you alone can send datagrams to it and (presumably) you can restrict who can send or receive on this group address. Alan Shi pointed out the model is pub-sub MOM.

UDP^TCP again#retrans is relevant.

FIFO — TCP; UDP — packet sequencing is uncontrolled
Virtual circuit — TCP; UDP — datagram network
Connectionless — UDP ; TCP — Connection-oriented

With http, ftp etc, you establish a Connection (like a session). No such connection for UDP communication.

Retransmission is part of — TCP; UDP — application layer (not network layer) must request retransmission

To provide guaranteed FIFO data delivery, over unreliable channel, TCP must be able to detect and request retransmission. UDP doesn’t bother. An application built on UDP need to create that functionality, as in the IDC (Interactive Data Corp) ticker plant.