[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha6-954-gbb7e6f0

[tridge at samba.org]

Hi Metze,

 > I'm in progress to fix the whole problem correctly, by fixing the socket
 > abstraction. The function socket_get_fd() is stupid and breaks the
 > abstraction.

socket_get_fd() is used for more than just the event code, it's also
used for things like setting socket options. I think it will take a
fair bit more work to remove it.

 > The caller should give a tevent_context to the socket layer and
 > callbacks for read and write, it's up to the socket layer how to trigger
 > them.

How will those socket layers do that triggering? The timed event
method is ugly (and hard to get error handling right), and the
"multiple recv" method that I put in the packet code (ie. "unreliable
select") can only really be done at the place where the data is
packetised, not below, or you will end up with moving the buffered
data up one level without solving the problem.

 > The packet.c code will also be obsoleted by a generic
 > tsocket_send[to]_queue_send/recv() and tsocket_recv_pkt_send/recv() code.

The primary motivation for the packet code wasn't to provide the
read/write layer, but to 'packetise' a stream. We had lots of bits of
code that tried to do the rather tricky task of buffering correctly so
that you grab just the right amount of data from a stream to form one
parsable lump of data, so it made sense to add a single layer that
handles all that complexity, relying only on a "is this a complete
packet" function from the protocol specific code.

I really like the packet.c functionality at the moment. It eliminates
a lot of complex processing from all of the protocol layers, and it is
flexible enough to handle all the protocols we've had to deal
with. I'd be reluctant to throw that away.

Cheers, Tridge