[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sockets Layer Counter Proposal



On Sun, 07 Oct 2012 16:22:38 -0400, Arthur A. Gleckler <srfi@xxxxxxxxxxxxxx> wrote:

On Sun, Oct 7, 2012 at 12:27 PM, Aaron W. Hsu <arcfide@xxxxxxxxxxx> wrote:

I suggest that they be merged simply because I don't think the differences
are very great, and I think having two SRFIs for this would only make
things more confusing.

Would you mind summarizing the differences?

Sure, I can try. I'll try to follow the general pattern of the SRFI document. I will begin with the relative equivalencies between the interfaces.

= Constructors and Predicates =

SRFI 106 Defines:

make-client-socket
make-server-socket
socket?

My sockets library defines:

create-socket
socket?

Differences:

Most notably, the make-client-socket and make-server-socket and the create-socket interfaces are different. The make-client-socket and make-server-socket procedures are somewhat tied to assumptions about the types of sockets that are being created, namely, INET sockets. The interface seems to restrict the socket creation to only TCP or UDP sockets, without any hope of scaling up to anything else without creating a whole new interface.

The create-socket procedure only accepts the domain, type, and protocol, which are optional flags in SRFI 106. It does not presume that the address is an INET address, and does not assume a specific listening or binding address for the server socket, which SRFI 106 does right now. Listening on a socket and binding a socket for service is done explicitly via the bind-socket and connect-socket procedures. Note that it is not necessary to make an explicit connection on a socket, but SRFI 106 does not permit one to have an unconnected socket.

= Socket Operations =

SRFI 106 Defines:

socket-accept
socket-send
socket-recv
socket-shutdown
socket-close

My library defines:

bind-socket
connect-socket
listen-socket
accept-socket
close-socket
shutdown-socket
send-to-socket
receive-from-socket

Differences:

bind-socket and connect-socket behavior are merged into the behavior of socket creation in SRFI 106 right now. This functionality is separate in my library. There is no listen-socket equivalent in SRFI 106. SRFI 106's version of accept-socket returns only a socket, while my version returns a socket and an address object. In my version of sendto, the user specifies an address as well as the buffer of data to send.

= Port Conversion =

I provide a separate library for converting sockets to ports, as sockets cannot always be conveniently or even safely converted to ports or back.

= Control feature =

I do not have a call-with-socket as the specification as given does not seem to be useful. It does not do anything except call socket with proc, which can be done by saying (proc socket).

= Constants =

SRFI-106 Defines:

AF_UNSPEC
AF_INET
AF_INET6
SOCK_STREAM
SOCK_DGRAM
AI_PASSIVE
AI_CANONNAME
AI_NUMERICHOST
AI_V4MAPPED
AI_ALL
AI_ADDRCONFIG
SHUT_RD
SHUT_WR
SHUT_RDWR

My library defines:

address-info/canonical-name
address-info/numeric-host
address-info/passive
socket-domain/unix
socket-domain/local
socket-domain/stream
socket-domain/datagram
socket-type/sequence-packet
socket-type/raw
socket-type/random
socket-protocol/auto
shutdown-method/read
shutdown-method/write
shutdown-method/read&write
send-to/dont-route
send-to/out-of-band
receive-from/out-of-band
receive-from/peek
receive-from/wait-all
receive-from/dont-wait

Differences:

I am unsure about the definitions in SRFI 106, but my library expects these constants to be defined as opaque objects exported from the library itself. These constants are not expected to be inspected or broken apart in any way, and should/must for all intents and purposes
appear as a single atom.

= Additional elements without equivalents in SRFI 106 =

In addition to the above, I also provide the following.

== Accessors for Sockets ==

socket-fd
socket-domain
socket-type
socket-protocol

== Additional Datatype constructors, predicates, and accessors ==

socket-option?
make-socket-option
define-socket-option-type
make-tcp-option
make-udp-option
make-raw-option
make-ip-option
tcp-option?
udp-option?
raw-option?
ip-option?
socket-address?
unix-address?
make-unix-address
unix-address-path
internet-address?
make-internet-address
internet-address-ip
internet-address-port
make-address-info
address-info
address-info-domain
address-info-type
address-info-protocol
address-info-address
make-socket-domain
make-socket-type
make-socket-protocol
socket-protocol?
protocol-entry-name
protocol-entry-aliases
protocol-entry-value
shutdown-method?
make-shutdown-method
make-send-to-option
make-receive-from-option
make-socket-condition
socket-condition?
socket-condition-who
socket-condition-syscall
socket-condition-type
socket-condition-message

== Additional Procedures ==

get-address-info
internet-address->string
string->internet-address
string->ipv4
register-socket-domain!
next-protocol-entry
get-protocol-by-name
get-protocol-by-constant
open-protocol-database
close-protocol-database
socket-maximum-connections
get-socket-option
set-socket-option!
set-socket-nonblocking!
socket-nonblocking?
socket-error
socket-raise/unless

Full documentation of these features is available in the indexed PDF on my website. However, it does address a few things that are currently listed as issues in the SRFI. Firstly, it take sthe view of creating schemely names for the POSIX equivalents. Secondly, it makes less critical the question about how many variables the SRFI need support. Socket options, domains, types, protocols, and socket addresses are all given the portable subset of their kinds (unix/local domains are an exception, but the library provides for the reporting of unsupported features), but the user can, at the user level, without requiring implementation support or additional implementation work, utilize additional variables and features by creating new socket options or the like which correspond to the system equivalents that they care about. This allows for code that makes use of implementation specific behavior to run on multiple scheme implementations that support the library without requiring explicit support for those extensions by the implementation: it is enough to implement the library alone. The interface is designed to be lightweight, relatively simple, and yet still scale to any number of extensions in an user extensible way.

Currently, most socket proposals do not do this. They provide only TCP and UDP (sometimes Local), without ever making it possible to scale beyond those things. My library provides ready TCP and UDP out of the box, but makes possible extending it. Moreover, the interface supports a number of patterns of usage that are not supported by the current SRFI proposal or many other interfaces. This includes, for example, the ability to have an unbound socket, or an unconnected socket.

--
Aaron W. Hsu | arcfide@xxxxxxxxxxx | http://www.sacrideo.us
Programming is just another word for the Lost Art of Thinking.