Re: Winsock wrappers

[Simon Josefsson]

Paolo Bonzini <address@hidden> writes:

>> Will such applications break if GnuTLS would use winsock wrappers
>> send/recv from gnulib instead of the system's?  I suspect it will, but
>> confirming that would be useful.
>
> Yes.

Thanks.

>>> You have to make a choice, and this in turn determines whether you want
>>> to use the gnulib send/recv replacements.  I see three possibilities:
>>>
>>> 1) Force users interested in Windows portability to provide their own
>>> send/recv implementation, and make the standard one only work under
>>> POSIX systems.  That would be backwards-incompatible, but very easy to do.
>> 
>> Maybe we could do the inverse:
>> 
>> 1') Force users interested in gnulib/POSIX portability on Windows to
>> provide their own send/recv implementations, and make the standard one
>> only work under Windows.
>
> Agreed, but note that I meant (1) as "set the default transport
> implementations to NULL under Windows".  1' just means "#undef send and
> recv before setting the default transport implementation", and do not
> include the send and recv modules of gnulib.

Ok, I see.  I think I prefer 1' since it is easier for Windows users,
and doesn't have any significant disadvantages.

>> Possibly libgnutls could define send/recv replacement functions that use
>> the gnulib winsock wrapper send/recv function instead of the system's,
>> for those applications that use gnulib winsock wrappers.
>
> No, I don't think it's worthwhile.

The lesser code the better.

> In fact send/recv are not necessary in the case of gnulib-provided (or
> in general POSIX-compliant) socket, as programs can use read/write too
> in that case.
>
> Maybe gnutls could provide adaptors from read/write to the signature
> needed for gnulib's transport functions?  That would be good enough to
> avoid duplication in client applications.

I think this was what I meant above, but I'm not sure I understand you.
What I see gnutls defining would be something like:

 ssize_t gnutls_gnulib_pull (gnutls_transport_ptr_t, void *, size_t);
 ssize_t gnutls_gnulib_push (gnutls_transport_ptr_t, const void *, size_t);

These would be implemented using gnulib's replacement send/recv
functions.

Then applications that have opened a socket via gnulib's module are
required to call:

  gnutls_transport_set_push_function (session, gnutls_gnulib_push);
  gnutls_transport_set_pull_function (session, gnutls_gnulib_pull);

I'm not sure I follow your read/write reference though.

This is sort of ugly, and maybe it is better for gnulib-applications to
specify these callbacks themselves.

Consider if gnulib's winsock.c implementation changed internally, then I
would need to bump the GnuTLS ABI just because of this.

I think I just talked myself out of doing this.

>>> 3) Same as (2), but also add a flag to a GnuTLS initialization function,
>>> that says what kind of sockets they are using, and in turn what should
>>> be used to read write (socket -> Winsock's recv/send after #undef'ing
>>> the definitions in gnulib's sys/socket.h; gnutls_socket -> libc
>>> read/write).  The flag would be used to initialize the send/recv
>>> function pointers to either Winsock's or gnulib's functions.  The flag
>>> would be a no-op under POSIX systems.  The default would be to use
>>> Winsock in order to provide backwards compatibility.
>> 
>> Isn't this the same as 1') but instead of a flag, the application needs
>> to set the send/recv wrapper to the functions provided by gnutls?
>
> More or less.  Actually, the flag could be just "use send/recv or
> read/write?" because of what I said above, and that means that it could
> be done without including lib/winsock.c or other similarly unwanted
> baggage into gnutls.

Are you saying that read/write on the socket would work under Windows?
Does it respect (non-)blocking settings?

/Simon