On Mon, Dec 13, 2004 at 10:04:25PM +1100, tridge@samba.org wrote:

> nmbd is not in Samba4 yet. When it is added, I expect it will contain
> very little, if any, of the Samba3 code, regardless of who contributed
> the original code.

is there any possibility of adding in a proxying system for 137-138?

such that, for example, the Wine team can implement the Win32
NETBIOS API, register NetBIOS names, and samba will "defend" the names
on behalf of Wine?

also, so that a NetBIOS name query made _by_ say a future Wine NetBIOS
API, the answer will actually come back, because it's proxied back via

i.e. is there any possibility to create something like a userland
netbios socket API, complete with sock_struct af_netbios, such that
both a future redesign of nmbd _and_ any other projects could benefit
from much cleaner and simpler code compartmentalisation?

i did give serious consideration to splitting down nmbd into several
smaller daemons - one for winsd, one for each NetBIOS nameset
registered [so one daemon for running as a member of a workgroup
handling WORKSTATION#0 and WORKGROUP#0, another one for running as a PDC
and registering WORKSTATION#20 and WORKGROUP#20 etc.]

if you recall i partially-successfully implemented a NetBIOS proxy in
1998: the sticking issue i had was whether to multiplex out to several
eth transports.

if i _had_ done that, then there was the risk of suffering from exactly
the same NetBIOS bug that NT suffers from: if i didn't... well, anyway,
i stopped researching it.

[as you are no doubt aware, the problem with nt is that if you
have two network cards, you must switch off binding NetBIOS to
one of them because otherwise you get NetBIOS name registration
on one interface broadcasting out to two interfaces, the
stupid code then goes and receives back two responses from
the UDP broadcast on the two separate interfaces, _both_
of those responses get fed back up to the NetBIOS layer,
at which point some idiot's code goes "if num_responses >