nng(7)

NNG presents a socket view of networking. The sockets are constructed using protocol-specific functions, as a given socket implements precisely one protocol.

Each socket can be used to send and receive messages (if the protocol) supports it, and implements the appropriate protocol semantics. For example, sub sockets automatically filter incoming messages to discard those for topics that have not been subscribed.

NNG sockets are message oriented, so that messages are either delivered wholly, or not at all. Partial delivery is not possible. Furthermore, NNG does not provide any other delivery or ordering guarantees; messages may be dropped or reordered (Some protocols, such as req may offer stronger guarantees by performing their own retry and validation schemes.)

Each socket can have zero, one, or many endpoints, which are either listeners or dialers. (A given socket may freely choose whether it uses listeners, dialers, or both.) These endpoints provide access to underlying transports, such as TCP, etc.

Each endpoint is associated with a URL, which is a service address. For dialers, this will be the service address that will be contacted, whereas for listeners this is where the listener will accept new connections.

Endpoints do not themselves transport data. They are instead responsible for the creation of pipes, which can be thought of as message-oriented connected streams. Pipes frequently correspond to a single underlying byte stream. For example both IPC and TCP transports implement their pipes using a 1:1 relationship with a connected operating system socket.

Endpoints create pipes as needed. Listeners will create them when a new client connection request arrives, and dialers will generally create one, then wait for it to disconnect before reconnecting.

Most applications should not have to worry about endpoints or pipes at all; the socket abstraction should provide all the functionality needed other than in a few specific circumstances.

The library API is documented at libnng(3).