[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Winsock wrappers
From: |
Simon Josefsson |
Subject: |
Re: Winsock wrappers |
Date: |
Thu, 09 Oct 2008 12:15:12 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux) |
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
- Winsock wrappers, Simon Josefsson, 2008/10/08
- Re: Winsock wrappers, Bruno Haible, 2008/10/08
- Re: Winsock wrappers, Simon Josefsson, 2008/10/09
- Re: Winsock wrappers, Paolo Bonzini, 2008/10/09
- Re: Winsock wrappers, Simon Josefsson, 2008/10/09
- Re: Winsock wrappers, Paolo Bonzini, 2008/10/09
- Re: Winsock wrappers,
Simon Josefsson <=
- Re: Winsock wrappers, Paolo Bonzini, 2008/10/09
- Re: Winsock wrappers, Simon Josefsson, 2008/10/09
- Re: Winsock wrappers, Bruno Haible, 2008/10/10
- Re: Winsock wrappers, Simon Josefsson, 2008/10/10
- Re: Winsock wrappers, Paolo Bonzini, 2008/10/10
- Re: getaddrinfo and sa_len, Bruno Haible, 2008/10/10
- Re: predefined CPP macros, Bruno Haible, 2008/10/10