smbwall

[Toomas Soome]

Andrew Bartlett wrote:
>
> Nicely illustrated!
> 
> > > It should be noted that none of this actually requires modification to
> > > Samba - even now!.  If you want to make this happen - simply write a
> > > daemon that listens on /dev/smb/0 - /dev/smb/x (where x is the maximum
> > > number of connections you expect to receive).  It can include its own
> > > code to read sessionid.tdb and the message sending code to bug the
> > > client with it.
> > >
> >
> > this daemon could even be the smbd itself - listening on its own
> > entries, for example.
> 
> Why?  smbd is sufficiently plump as it is - this is really something
> that can (and should) be done externally.
> 

just an floating idea:) not necessarily the best one... anyway, if I
think about this, the daemon listening/scanning all possible /dev/smb/*
entries is not the most effective. consider this big pts number example
-- there is no need to listen all pts entries to get the messages, just
listen those, which are actually in use. 

1. idea: if smbd will handle SMB session, then it should listen on "pts"
as well - to keep session + client information consistent. and there
could be the messaging daemon, it will get message and recipient data
from smbd and will deliver the  message to user. problem with this idea
is extra work for smbd to listen /dev/smb/X and to deliver message to
message daemon. since smbd and message daemon are on same host, there is
relatively little overhead with such communication.

2. idea: the message daemon will listen /dev/smb/ entries, not all, but
only entries registered by smbd. there should be registration protocol
implemented between smbd and the message daemon. problem is obvious -
what if smbd will not remove registration for sessions it handles.... 


toomas
-- 
Worst Vegetable of the Year:
	Brussel sprout.  This is also the worst vegetable of next year.
		-- Steve Rubenstein