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

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

[Ohad Rodeh]

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

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

[j h woodyatt]

On Thursday, August 23, 2001, at 12:02 , Ohad Rodeh wrote:
>
> A few comments about the new socket interface:
>
> [...]
> 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

I thought of this.  It makes getsockopt a pain to use.

Sure, you *could* use a pair of similar variant types, e.g.--

	type getsockopt_t = [ `Reuse | `Join | `Leave (* | ... *) ]
	type setsockopt_t = [ `Reuse | `Join of inet | `Leave of 
inet (* | ... *) ]

	val getsockopt: socket -> getsockopt_t -> setsockopt_t
	val setsockopt: socket -> setsockopt_t -> unit

...but then you have to do a pattern match on the result of getsockopt 
and that seems overly messy to me.  And, if you're like me and you want 
to communicate with weird Darwin NKE's, it's difficult to add new socket 
options.

With my proposal, you get to write code that looks like this:

	let acceptconn = Unix.SO_ACCEPTCONN.get socket in f acceptconn

As opposed to:

	match Unix.getsockopt socket `Unix.SO_ACCEPTCONN with
	| `Unix.SO_ACCEPTCONN yes -> f yes
	| _ -> assert false

Adding a new socket option is a simple thing.  Define a new module with 
the type of the option, and the values of the level and the name.  Then 
use the functorial.  (Though, the more I think about it, I suspect the 
'external' interface semantics are going to make it easier if the the 
input signature contains the external functions for the specified type.  
This is an extra complication, but not one that can't be managed, I 
think.)

> Anyway, have fun with caml.

Loving it.  I never want to go back to C++ or Perl again.


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

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

[j h woodyatt]

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