Berkeley sockets
{'<entity_0>': 'application programming interface', '<entity_1>': 'Berkeley Software Distribution', '<entity_2>': 'inter-process communication', '<entity_3>': 'Berkeley socket API', '<entity_4>': 'Berkeley sockets', '<entity_5>': 'socket'}
[['Berkeley sockets', 'use', 'inter-process communication'], ['Berkeley sockets', 'instance of', 'application programming interface'], ['Berkeley sockets', 'named after', 'Berkeley Software Distribution'], ['Berkeley sockets', 'alternative', 'Berkeley socket API'], ['Berkeley sockets', 'alternative', 'socket']]
<entity_4> is an <entity_0> (API) for Internet sockets and Unix domain sockets, used for <entity_2> (IPC). The term POSIX sockets is essentially synonymous with <entity_4>, but they are also known as <entity_1> sockets, acknowledging the first implementation in the <entity_1>. As the <entity_3> evolved and ultimately yielded the POSIX <entity_5> API, certain functions were deprecated or removed and replaced by others. In general, they include: The <entity_3> typically provides the following functions: The function <entity_5>() creates an endpoint for communication and returns a file descriptor for the <entity_5>. Historically, in <entity_1>-derived systems, the state of a <entity_5> descriptor is undefined if the call to connect fails (as it is specified in the Single Unix Specification), thus, portable applications should close the <entity_5> descriptor immediately and obtain a new descriptor with <entity_5>(), in the case the call to connect() fails. These functions are not strictly a component of the <entity_1> <entity_5> API, but are often used in conjunction with the API functions. The following lists a sampling of protocol families (preceded by the standard symbolic identifier) defined in a modern Linux or <entity_1> implementation: A <entity_5> for communications is created with the <entity_5>() function, by specifying the desired protocol family (PF_-identifier) as an argument.
['application programming interface']