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

[JINMEI Tatuya / 神明達哉]

Sorry for the delayed response.

At Thu, 21 Oct 2010 18:28:40 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> 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 *.

Okay, this is probably something I cannot agree with.

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

I'm not sure what this means.

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

I talked about what is sent over the wire.

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

Hmm, I'm not sure we talked about the same thing.  I meant that
BSD-derived systems had sa_len, sin_len, sin6_len, etc, and the
current code didn't set these fields properly.  At that time I
also thought some BSD-derived kernels rejected a bind() call if sa_len
of the specified sockaddr structure isn't set correctly.  But
apparently I was wrong about the latter point; from a quick check all
major BSD-derived kernels simply ignore sa_len.

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

For quicker integration, I tend to agree it makes sense.  But I have
some additional comments about extendability.  To be continued...

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.