Re: [Caml-list] Unix.socket_option in ocaml-3.0.2

["Ohad Rodeh" <ORODEH@il.ibm.com>]

A few comments about the new socket interface:

1. It is an improvement over what we had previously.
2. There is bug in the socket options interface for WIN32 platforms
(already fixed in the CVS).
3. I've asked for multicast additions a while ago, they exist in Ensemble
for ages.
4. Why not use a simple sum type for socket options. Here's what we do in
Ensemble:

     (* Options passed to setsockopt.
      *)
    type socket_option =
      | Nonblock of bool
      | Reuse
      | Join of inet
      | Leave of inet
      | Ttl of int
      | Loopback of bool
      | Sendbuf of int
      | Recvbuf of int
      | Bsdcompat of bool

    (* Set one of the above options on a socket.
     *)
    val setsockopt : socket -> socket_option -> unit

Anyway, have fun with caml.

  Ohad.



j h woodyatt <jhwoodyatt@mac.com>@pauillac.inria.fr on 23/08/2001 01:45:10

Please respond to jhw@wetware.com

Sent by:  owner-caml-list@pauillac.inria.fr


To:   caml-list@inria.fr
cc:
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



-------------------
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