From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 4BC507FA1F for ; Fri, 11 Jul 2014 16:13:38 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of vb@luminar.eu.org) identity=pra; client-ip=94.23.24.152; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="vb@luminar.eu.org"; x-sender="vb@luminar.eu.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of vb@luminar.eu.org designates 94.23.24.152 as permitted sender) identity=mailfrom; client-ip=94.23.24.152; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="vb@luminar.eu.org"; x-sender="vb@luminar.eu.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@luminar.eu.org designates 94.23.24.152 as permitted sender) identity=helo; client-ip=94.23.24.152; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="vb@luminar.eu.org"; x-sender="postmaster@luminar.eu.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAFTwv1NeFxiY/2dsb2JhbABZgmokUoNLgTG8WIdCAYELFnWEAwEBBAEjDwFFAQULCxgCAgUWCwICCQMCAQIBRQYNAQUCAQGINgkDCa0wmQEXgSyIUYUKDzMHgneBTAEEnE+SUoNGgW4 X-IPAS-Result: AjUFAFTwv1NeFxiY/2dsb2JhbABZgmokUoNLgTG8WIdCAYELFnWEAwEBBAEjDwFFAQULCxgCAgUWCwICCQMCAQIBRQYNAQUCAQGINgkDCa0wmQEXgSyIUYUKDzMHgneBTAEEnE+SUoNGgW4 X-IronPort-AV: E=Sophos;i="5.01,643,1400018400"; d="scan'208";a="84806914" Received: from luminar.eu.org ([94.23.24.152]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 11 Jul 2014 16:13:37 +0200 Received: from [IPv6:2001:41d0:fc9c:c500:48e8:d311:dad1:73fd] (unknown [IPv6:2001:41d0:fc9c:c500:48e8:d311:dad1:73fd]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by luminar.eu.org (Postfix) with ESMTPSA id A568F60A41; Fri, 11 Jul 2014 16:13:36 +0200 (CEST) Message-ID: <53BFF110.8080900@luminar.eu.org> Date: Fri, 11 Jul 2014 16:13:36 +0200 From: "Vincent B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?UmFwaGHDq2wgUHJvdXN0?= CC: caml-list@inria.fr References: <53BD7D68.1090409@luminar.eu.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] IPv6 zone-id On 11/07/2014 10:03, Raphaël Proust wrote: > On Wed, Jul 9, 2014 at 6:35 PM, Vincent B. wrote: >> > The Unix module does not make possible to use IPv6 link-local >> > addresses. >> > >> > This is due to the fact that the "sockaddr" type in Unix is not as >> > complete as its C counterpart, especially it lacks zone-id information >> > that is required to use such addresses. >> > >> > Since I needed such features, I started writing a library >> > (http://github.com/vbmithr/ocaml-sockopt), unfortunately, given that >> > every networking piece of code written in OCaml use the primitives of >> > the Unix module, I would have to patch all networking code I want to >> > use which is not very convenient. > Is it possible to make a new networking module using Cstruct to manage > sockaddr and such? Not sure what you mean by "using Cstruct to manage sockaddr…" but yeah, it is just a matter of binding the relevant C primitives. The Unix module is far from exhaustive, yet it is the normal entry point for doing networking in OCaml. The issue here is to be able to use existing networking OCaml code. >> > >> > So I'm in the process of writing a patch for OCaml and I'm taking the >> > approach of extending the sockaddr type like this: >> > >> > type sockaddr_raw (* a real struct sockaddr *) >> > >> > type sockaddr = >> > ADDR_UNIX of string >> > | ADDR_INET of inet_addr * int >> > | ADDR_RAW of sockaddr_raw >> > >> > And then upgrading all the Unix code that uses type sockaddr. >> > >> > This approach seems to me the most conservative towards existing >> > code. Should I continue in this direction or this design is not the >> > optimal one ? > Although very conservative towards the existing codebases, I don't > like this approach for the following reasons. > > The same sockaddr can be represented in different ways (which means > that equality becomes non-trivial, and the choice of representation is > non-obvious for programmers). That is indeed an issue. > The Unix module is build as abstractions from the underlying system, > adding a sockaddr_raw defeats that. It becomes abstractionless. This is an issue as well. > Additionally, is sockaddr_raw completely opaque? what > constructors/destructors are available? Unix.getifaddrs would return a RAW sockaddr for example. You raise valid points. The best approach IMO would be to extend the abstraction to accomodate for the other features. The root issue is that type sockaddr in OCaml is not abstracting enough of the C interface: A struct sockaddr is more than what is abstracted from it. Changing the type sockaddr in OCaml would break all existing networking code. That's why I was looking for advice basically. I'm gonna look for alternative OCaml stdlib to see if there is anything better for networking. Thanks for you answer :) Vincent