www.cendio.com

Bug 1892

Summary: Scanner redirection based on the SANE network protocol
Product: ThinLinc Reporter: Peter Åstrand <astrand@cendio.se>
Component: OtherAssignee: Peter Åstrand <astrand@cendio.se>
Status: CLOSED WONTFIX QA Contact: Bugzilla mail exporter <bugzilla-qa@cendio.se>
Severity: Enhancement    
Priority: P2 CC: samuel@cendio.se
Version: 1.4.1   
Target Milestone: 4.8.0   
Hardware: PC   
OS: Linux   
Acceptance Criteria:
Bug Depends on: 2227    
Bug Blocks:    
Attachments: Half-finished patch against SANE CVS for data port elimination

Description From cendio 2006-04-12 10:08:32
The LTSP project supports scanners, via SANE. I guess we could perhaps do the
same.
------- Comment #1 From cendio 2006-10-26 11:29:52 -------
I've investigated this now. I've looked at four solutions:

1) Using a scanner with built-in network support. The problem is that these
kinds of scanners are very rare. I've only found one that it's supported by
SANE: Dell 1600n. This is a large and expensive multi-purpose machine and it's
not even sold anymore. Another major problem with this solution is that it does
not provide any security, since it's communicating outside our SSH tunnel. 

2) Use a network "document server", like AXIS 70U or 7000. One problem is cost:
70U currently costs 6681 SEK at Inwarehouse. Another one is operation: The idea
is that you e-mail the document to predefined adresses. This is not very
flexible. Also, this means that we have no encryption. 

3) Use USB redirection via libusb. One problem is that Linux libusb lacks
network support. Sun Ray supports scanner redirection via libusb, but they have
their own "hacked" libusb. Another drawback is that the solution is tied to USB:
We cannot support network scanners or interfaces like SCSI, Parallell, Firefire
etc. 

4) Use SANEs built-in network support. We could ship a "saned" network daemon
with the TL client that dynamically links to libsane. This way, TL client would
act just like a local scanner application. This principle is also used with
tlclients other redirection services. It would support any kind of
(preconfigured) scanner, regardless of interface etc. It would even be possible
(in theory) to run export a scanner via tlclient from inside a TL session. 

The SANE network protocol is not without problems, however. The main issue is
that is used dynamically allocated data ports, just like FTP. This does not work
with our SSH tunnels. I've started looking about this problem and it does indeed
look like the protocol can be modified to transfer the date inside the main TCP
connection. 

A time estimation for implementing scanner support via SANE is:

Finishing the elimination of the data port: 8h
Implement support for backwards compatibility: 3h
Configurable port number for the net backend: 4h
Adapt tlclient to call "saned": 4h
Package "saned", documentation: 8h

In total, 27h, plus the 5 already spent. 
------- Comment #2 From cendio 2006-10-26 11:34:13 -------
Created an attachment (id=217) [details]
Half-finished patch against SANE CVS for data port elimination

The patch is against SANE CVS as of 2006-10-26. It implements the new
SANE_NET_START2 procedure. It also defines a skeleten for the SANE_NET_READ
procedure. What remains is to implement this, in both end. This requires
creating a pipe or socketpair which can be fed to the application. We need to
use forking/threading to fill this pipe. Also, need to think about
blocking/nonblocking. We should try to aim to make SANE_NET_READ as similiar to
sane_read() as possible, though. 
------- Comment #4 From cendio 2008-05-26 13:14:51 -------
Interesting URL: 
http://blogs.sun.com/ThinkThin/entry/sun_ray_connected_scanners_in
------- Comment #5 From cendio 2010-04-29 16:04:01 -------
I've submitted a tracker for this:

https://alioth.debian.org/tracker/index.php?func=detail&aid=312478&group_id=30186&atid=410366
------- Comment #6 From cendio 2010-05-10 14:14:16 -------
http://www.scanner-news.com/network-scanning-solutions/network-twain-scanners-is-your-driver-%E2%80%9Ctrue%E2%80%9D/
is interesting: It states that some network TWAIN drivers simply supports
importing images from a folder:

"The user opens their scanning application and clicks “scan”. The Network TWAIN
driver opens and gives the user the option to import a document that has
already been scanned. Typically these drivers assume that you have already
scanned the documents by physically going to the scanner. In most cases these
scanned documents get stored to a network share folder or within the scanner’s
memory. We call this the “push” method because you “push” the scans to a
directory and then access them later. Network TWAIN drivers that function like
this are essentially a TWAIN compatible file import feature; not a “true”
network TWAIN driver. This can be useful if your scanning application doesn’t
have a file import feature and only allows you to scan documents in. You can
also purchase 3rd party TWAIN drivers created specifically for file import as
well."

In the case with our "TLCOS hack" (see bug 2227), this could actually be very
useful. 
------- Comment #8 From cendio 2010-05-11 14:44:35 -------
The TLCOS/localdrives solution is now covered by bug 3526. When implementing
this bug, we should remove that solution, if we have decided to include it. 
------- Comment #9 From cendio 2017-02-27 11:59:49 -------
(In reply to comment #1)
> I've investigated this now. I've looked at four solutions:

> 3) Use USB redirection via libusb. One problem is that Linux libusb lacks
> network support. Sun Ray supports scanner redirection via libusb, but they have
> their own "hacked" libusb. Another drawback is that the solution is tied to USB:
> We cannot support network scanners or interfaces like SCSI, Parallell, Firefire
> etc. 

10 years later, a few things have changed, so I now believe that the best way
to handle scanners is by supporting a libusb based USB redirection. This is the
de facto solution selected by IGEL, Sun Ray, and to some extent Microsoft. See
bug 310.
------- Comment #10 From cendio 2017-03-27 14:16:28 -------
(In reply to comment #9)

> 10 years later, a few things have changed, so I now believe that the best way
> to handle scanners is by supporting a libusb based USB redirection. This is the
> de facto solution selected by IGEL, Sun Ray, and to some extent Microsoft. See
> bug 310.

Closing in favour of bug 310 and bug 6207.