Mind if I read your code?

Christopher R. Hertel crh at ubiqx.mn.org
Fri Jan 2 18:39:08 GMT 2004


On Thu, Jan 01, 2004 at 11:41:45PM +0000, Andrew Bartlett wrote:
:
> > One issue brought up here before, in a less politic
> > way than I would have liked, is the port-grabbing one.
> >  Do you folks see a way we might be able to run
> > NetBIOS servers through some plug-in mechanism?
> 
> I'm not sure about NetBIOS servers - nobody really writes these today,
> but I don' think you really need that.

Not sure what is meant here, but...

NetBIOS is an API, and Samba doesn't actually implement that API.  Samba 
bypasses NetBIOS and goes directly to the NBT layer.  The problem, as I 
understand it, is that Samba "hogs" control over the NBT layer.  Other 
applications and services that want to communicate using NBT (possibly via 
a NetBIOS API) can't easily do that.

We have talked about this kind of thing before.  Things like creating an 
API to allow a separate application or service to register NetBIOS names 
so that it can send and receive NetBIOS Datagrams and Session Messages.

On my own, I've been toying with the idea of an NBT Daemon.  I've got some
code but not enough time to make it fly yet.  The NBT Daemon would handle
all of the muck and details of the NBT layer.  It would also have an API
(similar to NetBIOS, but probably not the same) so that you could write
code that would talk and listen on the "NetBIOS LAN".  Tridge has pointed
out some potential security pitfalls here, but the basic idea is sound.

There's a lot more to such a thing than I can sputter forth here.  The key 
would be integrating it with Samba so that a single system could run both.  
Issues of SMB server speed have been raised but I don't think that would 
be a problem because the only needed change to the Server Service would be 
a quick lookup on the CALLED NAME (which we probably already do in order 
to handle virtual servers).  If the Session Request isn't intended for 
smbd then it gets handed off.

:
:
> > Very true.  Alexandre and some of the other Wine folks
> > have expressed the opinion that we shouldn't be doing
> > SMB for files anyway--the kernel should be doing it
> > all, so we can treat remote files the same as local
> > ones, and Linux programs and Windows ones will see
> > consistent behavior, all without straying from a GPL
> > license.
> 
> Going via POSIX is suboptimal, you do get much better semantics going
> direct to CIFS.  It would be good if we could work out some way that
> could happen.

Agreed.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org


More information about the samba-technical mailing list