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

[Michal 'vorner' Vaner]

Hello

On Wed, Oct 27, 2010 at 04:35:33PM +0900, JINMEI Tatuya / 神明達哉 wrote:
> > 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.

Still I didn't see any reasonable clean and simple solution to convert
vector<uint8_t> to int in architecture-independent way. Calling a function with
(&number, sizeof number) is clearly simpler and more convenient, than writing
conversion from format I can not possibly know by definition. Not to talk about
calling it just as readVar(number) in the case of template function.

The think we can disagree about is what approach has higher probability of
having bugs in it.

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

Well, every documentation says „do not mix writes to stdout with writes to fd 1“
(same with stdin, cout, etc), because stdout/cout is wrapper around fd 1 and can
have some internal buffers, state around it and so on, and it could interleave
data or get confused.

So either we need to make sure to flush every time, make sure it does not
buffer, etc, or not mix it. And we need to use the fd lowlevel way, because we
are not able to send the socket any other way now.

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

Well, I can send the data of string. The point I was making was, if there's a
template function that does write(&data, sizeof data), there can be specialized
one for strings that does:

size_t len(string.size());
write(&len, sizeof len);
write(string.c_str(), len);

This would hide the way data are sent over the wire from the application, it
would still have the same interface. It is the same way as you do not have to
care that vector<bool> is represented differently inside (8 bools per byte). I
fully agree that sending a pointer to anything does not make any sense at all.

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

Hmm, we didn't talk about the same thing.

Odd, my man 7 ip does not talk about any sin_len at all. The only length thing I
see anywhere is addrlen as separate bind argument. Where should I look for the
sin_len?

Anyway, it is a long time now and I'm in the R-team, so I think I will just dump
the ideas I had and still remember somewhere on wiki and hope someone finishes
it.

Have a nice day & thanks for the input

-- 
This email has not been checked by an antivirus system.
No virus found.

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/20101027/96668d55/attachment.bin>