Berkeley Sockets Interface

This document standardizes the Smalltalk view of the Berkeley Sockets interface found on many operating systems. Since not all smalltalks will be running on a system providing Berkeley Sockets this part of the dCSSS is optional.

It seems to me that in units of usefulness implementing against the 4.4BSD socket API is the best way to start. It provides an underlying primitive API that exists on practically all current Unix systems. Microsoft's Winsock 1.1 API was based on the BSD API, and this heritage is evident in the newer Winsock2 API. As such, a Smalltalk implementation requiring 4.4BSD behavior can be made on top of Winsock, with only minor primitive changes (i.e., using closesocket() instead of close()). I'm not familiar with the Mac way of doing sockets, but there are two things to consider: 1) MacOSX is going to replace the MacOS8/9 socket implementation and will provide true BSD sockets and 2) the MacOS8/9 socket API ought to be capable of providing a BSD-like interface given the right abstraction layer.

I would make the low-level Smalltalk implementation assume BSD sockets. Non-BSD socket implementations can provide BSD wrappers to their non-BSD socket API elements.

What looks like a good overview of 4.4BSD sockets can be found at www-users.cs.umn.edu/~bentlema/unix/advipc/ipc.html.

For the purpose of producing an official standard for socket I/O, it is desirable to separate sockets from streams because sockets are the I/O sources and sinks used by a stream implementation. A stream shoudn't have to know the type of its underlying data source or sink. However, a stream very well might need to ask its data source/sink to execute a certain high-level operation such as read(), write(), close(), etc. so that operations can be customized for the underlying type of the source/sink. The Linux kernel does this by encapsulating such operations in struct file_operations structures that provide per-source definitions for operations like poll(), read(), lock(), release(), etc.

We should also examine the relationship between sockets and other file descriptor (fd) based I/O types. A BSD socket is represented in the operating system kernel as a fd, just like any regular file, and as such there are many fd operations such as fstat() and dup() that can be used on sockets but which shouldn't be defined in the socket API.

The following operating system functions should be assumed:

1. socket()
2. socketpair()
3. bind()
4. getsockname()
5. connect()
6. getpeername()
7. send()
8. sendto()
9. recv()
10. recvfrom()
11. sendmsg()
12. recvmsg()
13. getsockopt()
14. setsockopt()
15. listen()
16. accept()
17. shutdown()
18. close() (may be closesocket())