[bind10-dev] Socket creator and low-level code

[Michal 'vorner' Vaner]

Hello

On Fri, Oct 22, 2010 at 12:26:45AM +0900, JINMEI Tatuya / 神明達哉 wrote:
> - using a safe interface such as std::vector if we need to keep the IO
>   primitive that needs to expect partial read, or

With vector I still have a difficulty making it the type I want. It is much
easier with void *.

> - use a real socket with recv(MSG_WAITALL).  then we don't even have
>   to need a separate read_data function.  it can simply be:
>   return (recv(fd, &variable, sizeof(T), MSG_WAITALL) == sizeof(T));
>   or

Actually, it is a real socket. It is impossible to send socket over a pipe, it
seems (at last on my system it fails). So I just want to dup the socket to
stdio, because these are well defined fd numbers I'm sure I can get. I could
give the fd as a program argument as well.

Thanks for the note about MSG_WAITALL, I didn't know that one. It seems it
wouldn't work on signal, but the process shouldn't get signals anyway.

> - if we want to keep using stdin and stdout, use std::iostream instead
>   of the lower level API

It would be problematic with internal buffering. Sending the fd probably needs
the previous data to be already in the socket.

> std::string won't work with this approach, because passing an address
> to an object of std::string is meaningless.

I don't understand what you mean. I surely can assign to a std::string object
and passing a reference to that object into a function makes sense. What is sent
over the wire is a different thing.

> Having said that, I would actually propose one different type of
> approach, not actually related to the pointer vs higher-level API
> discussion.
> 
> I wonder whether we can pass addresses and ports as a string, which
> will be represented in the form of length + C-string.  Then we can use
> getaddrinfo(3) to support both IPv4 and IPv6 in unified code, without
> worrying about portability of sa_len (btw your current code has this
> portability bug).  The main drawback of this approach is exchanging
> variable-length data may be considered riskier, but, I would accept
> that risk if we use safer API.

Well, I read about sa_len and I do not think this is a bug, because I pass the
value there. If the bind() has different integral type, it would get
auto-converted on the function call. The problem arises when passing a pointer
to it to some function returning the address, because it can have a different
length.

But that would require a bigger rewrite, actually. I can either change the
internal parts as I said (current tests test the external behaviour, so it would
need only small changes) and get it into some defined point. Or there will be
major change of the protocol, but then all the tests would need to change as
well and so, so I would leave it to someone else, as this does not really belong
to R-team.

So, what do you think? Does it make sense to change the use of the read/write to
a template functions, eliminate type casts and clean it up of pointer as much as
possible for me?

Thank you

-- 
This email has been checked by an automatic damage possibility check system.
It can contain harmful instructions if read backwards.
Internal checker ID: lacol.cr/cte/ << tlah ohce

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101021/c9a8b520/attachment.bin>