Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Unix.socket_option in ocaml-3.0.2
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: j h woodyatt <jhwoodyatt@m...>
Subject: [Caml-list] Unix.socket_option in ocaml-3.0.2
everyone--

I noticed that the Unix library module in 3.0.2 has an improved 
interface for socket options.  I am grateful for the ability to set 
options that are not boolean values, but there are other options that 
are still out of reach for me.  Specifically, the IP_MULTICAST_XXXX 
options, which want IP address values.

I know you could just add more setsockopt_foo and getsockopt_foo 
functions, but I want to propose an alternative interface.  Please 
consider something like the following as a possible addition to unix.mli 
(and the appropriate implementation in unix.ml):

---- BEGIN EXCERPT

type socket_option_level and socket_option_name

module type SocketOption_sig = sig
	type t
	val level: socket_option_level
	val name: socket_option_name
end

module type SocketOption_t = sig
	type t
	val set: fd:file_descr -> t -> unit
	val get: file_descr -> t
end

module SocketOption(S: SocketOption_sig) : SocketOption_t with type t = 
S.t

module SO_DEBUG: SocketOption_t with type t = bool
module SO_BROADCAST: SocketOption_t with type t = bool
module SO_REUSEADDR: SocketOption_t with type t = bool
module SO_KEEPALIVE: SocketOption_t with type t = bool
module SO_DONTROUTE: SocketOption_t with type t = bool
module SO_OOBINLINE: SocketOption_t with type t = bool
module SO_ACCEPTCONN: SocketOption_t with type t = bool
module SO_SNDBUF: SocketOption_t with type t = int
module SO_RCVBUF: SocketOption_t with type t = int
module SO_ERROR: SocketOption_t with type t = int
module SO_TYPE: SocketOption_t with type t = int
module SO_RCVLOWAT: SocketOption_t with type t = int
module SO_SNDLOWAT: SocketOption_t with type t = int
module SO_LINGER: SocketOption_t with type t = int option
module SO_RCVTIMEO: SocketOption_t with type t = float
module SO_SNDTIMEO: SocketOption_t with type t = float

type ip_mreq = inet_addr * inet_addr

module IP_ADD_MEMBERSHIP: SocketOption_t with type t = ip_mreq
module IP_DROP_MEMBERSHIP: SocketOption_t with type t = ip_mreq
module IP_MULTICAST_IF: SocketOption_t with type t = inet_addr
module IP_MULTICAST_TTL: SocketOption_t with type t = int
module IP_MULTICAST_LOOP: SocketOption_t with type t = bool

module TCP_NODELAY: SocketOption_t with type t = bool

----- END EXCERPT

Comments?  (I know.  Some of these options are more commonly available 
than others.  I'm specifically interested in calling attention to the 
functorial interface I'm proposing.)

I'm curious to know what are the tradeoffs associated with doing it this 
way.  I can see how the nested modules are fairly easily done, but the 
functorial might be harder, but still possible (maybe with more members 
in the input signature, I don't know yet).

Any ideas on how space and time performance would be affected?


--
j h woodyatt <jhw@wetware.com>
"You're standing on sacred ground.  Many strange and wonderful
things have transpired right where you're standing."
                                               --unattributable
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr