![]() Sockets configured as streams (discussed below) are bidirectional, and control follows a client/server pattern: the client initiates the conversation by trying to connect to a server, which tries to accept the connection. The forthcoming example covers network sockets, but the sample server and client programs can run on the same machine because the server uses network address localhost (127.0.0.1), the address for the local machine on the local machine. Despite these implementation differences, the IPC socket and network socket APIs are the same in the essentials. ![]() Network sockets need support from an underlying protocol such as TCP (Transmission Control Protocol) or the lower-level UDP (User Datagram Protocol).īy contrast, IPC sockets rely upon the local system kernel to support communication in particular, IPC sockets communicate using a local file as a socket address. IPC sockets (aka Unix domain sockets) enable channel-based communication for processes on the same physical device ( host), whereas network sockets enable this kind of IPC for processes that can run on different hosts, thereby bringing networking into play. Just as pipes come in two flavors (named and unnamed), so do sockets. This article moves from IPC at the high end (sockets) to IPC at the low end (signals). The first article focused on IPC through shared storage (files and memory segments), and the second article does the same for basic channels: pipes (named and unnamed) and message queues. ![]() ![]() This is the third and final article in a series about interprocess communication (IPC) in Linux. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |