Difference between revisions of "Messaging"

(new approaches (unfinished))
(links to patches)
Line 27: Line 27:
  
 
[[Image:messaging-socket.png]]
 
[[Image:messaging-socket.png]]
 +
 +
You can get the patch with this messaging approach for samba3 - [http://samba.org/~ab/dralex/samba3-unix-dgram-socket-messaging.patch]
  
 
=== UNIX stream sockets implementation ===
 
=== UNIX stream sockets implementation ===
Line 33: Line 35:
  
 
[[Image:messaging-stream-socket.png]]
 
[[Image:messaging-stream-socket.png]]
 +
 +
You can get the patch with this messaging approach for samba3 - [http://samba.org/~ab/dralex/samba3-unix-stream-socket-messaging.patch]
  
 
== Testing and benchmarking ==
 
== Testing and benchmarking ==
  
 
You can test messaging speed with LOCAL-MESSAGING test from [[Samba4]] [[smbtorture]].
 
You can test messaging speed with LOCAL-MESSAGING test from [[Samba4]] [[smbtorture]].

Revision as of 20:32, 18 May 2006

Multiple smbd (and nmbd, winbindd) processes usually run simultaneously - a main daemon process and couple of connections processes. Samba code has special API that allows different processes send messages each other. There are two implementations of the messaging code - different in current Samba3 and Samba4 code.

TDB implementation (samba3 and trunk)

This implementaion uses TDB file for storing messages and UNIX signals for notifying message receiver.

All messages are stored in messages.tdb file (one can find it in var/locks directory). Each message is just a database record that has six fields:

  • messaging version (there is only one version now - 1)
  • message type
  • sender process id
  • receiver process id
  • message data length
  • message data

There are lot of message types in Samba3, you can see them all in include/messages.h file.

Process sends a message to other process with special function message_send_pid and to all processes with message_send_all. Each process should call message_dispatch routinely to check if messages were received and run appropriate handler.

Messaging-tdb.png

(you can get image source here - [1])

UNIX datagram sockets implementation (samba4)

This implementation uses UNIX domain sockets. Each smbd listens on a unix domain (datagram) socket with the name based on its pid. All sockets are located in var/locks directory. One message is packed into one datagram, so now we have message size problem - there is no way to send messages with size larger than allowed by a datagram.

Messaging-socket.png

You can get the patch with this messaging approach for samba3 - [2]

UNIX stream sockets implementation

This implementation uses UNIX domain sockets too, but stream sockets. Each smbd listens on a unix domain (stream) socket with the name based on its pid. All sockets are located in var/locks directory. When a message is about to be sent, the sender connect(2)s to that socket and sends the whole message. As stream sockets are bidirectional, the response can use the same socket. This could be implemented by a message socket cache that holds for example the last N (e.g. 10) connections. All data transfering is being done asynchronousy with main a select loop (message_dispatch does all connections-related work).

Messaging-stream-socket.png

You can get the patch with this messaging approach for samba3 - [3]

Testing and benchmarking

You can test messaging speed with LOCAL-MESSAGING test from Samba4 smbtorture.