infiniband: ?

[tridge at samba.org]

Peter,

 > That was my 1st proposal (not published), and then after Alexander B. exposed 
 > me the need of _real_ a socket-like interface (2nd)

If we can get a socket like interface at no cost, then great, but I
don't think its essential.

What I think the transports will need to provide is:

 - a way to return a list of what nodes are on the system

 - a way to send a message to a specified node

 - hooks to allow events (incoming messages etc) to hook into our
   events layer. For IB that will probably be channel->fd 

 - a way for the event hooks to call a function to say that a message
   has arrived, plus who it is from, size etc

None of this is particularly socket like :)

 > It would have a need of a dedicated process for ib-specific event handling, 
 > communicating to other user processes via e.g. unix domain sockets (or 
 > better).

I envisage we will have a single dispatched daemon per node. This will
handle all the CTDB protocol traffic, plus talk to all the smbd
processes across a unix domain socket.

 > Q1: how do you imagine [TCP/IP-] connection buildup? AFAIK the common design 
 > is to dedicate 1 (forked) process for each connection (as samba works now).
 > I'd need a scenario for adding a node runtime as well.

We will have a single process for all the CTDB traffic on a
node. There will be many smbd processes who talk to that one CTDB
process.

 > That's why I've been curious where (and how) this layer is applied 
 > (dispatcher? smbd?).

The code in my little bzr tree currently just has one process - it
doesn't have the equivalent of the smbd process. That is to keep the
initial development simple, it isn't how things will run eventually :)

Cheers, Tridge