How to migrate this code in my System app packages?

[niuliwan]

I hava a mini OS running on phones ,what should we do to compile this code to a app? If we need to migrate a compiler for the go language or any other things?

[alexpevzner]

You mean, you want to compile this code to the executable that can run on your OS?

Yes, you need a working Go compiler with working Cgo support, plus you need the libusb, plus your need a working DNS-SD infrastructure (Linux uses avahi)

And please note, ipp-usb only exposes USB printers to the localhost via HTTP. You also need some "client" stuff for these HTTP endpoints for printing and scanning

[niuliwan]

Thank you !
Yes,we want to complile a set of customized code based on UNIX to the OS image that can run on our Hardware.
But we don't have these things like Go compiler or DNS-SD infrastructure in our codes. If we want use your code, we have to perfect these And that's a lot of work for us. I'm evaluating whether I need to develop a feature that's the same as yours. I'd like to get some suggestions for you.

[niuliwan]

[alexpevzner]

As printer may be connected and disconnected in any time, and (on desktop at least) multiple printers may be connected, some signalling mechanism is required that allows ipp-usb to tell applications that printer is available. On Linux, DNS-SD (Avahi) is used for this purpose, which is (for Linus) is very natural way, because it makes things very consistent with network printers discovery (from the applications' point of view, there is no big difference between IPP-USB printer, exposed to localhost, and network printer, accessible via WiFi or Ethernet).

Cgo is only needed to deal wil libusb and avahi libraries. In theory, these layers are isolated in the usbio_libusb.go and dnssd_avahi.go files respectively and can be rewritten on a top of any alternative API that implements appropriate functionality.

You may also consider looking to the ippusb_bridge project. It was written by Google for their ChromeOS and was inspired by the ipp-usb project. The reason why Google wrote their own implementation is the ipp-usb executable size: Go, due to statical linking, tends to produce large executables. The ippusb_bridge is written in Rust and noticeably smaller.

Please note, that it took from Google several month to reimplement ipp-usb in Rust. Please note also, that functionality of ippusb_bridge is not as complete as of ipp-usb. In particular, it doesn't contain a framework for work-around firmware problems of several printers, which ipp-usb does.

[niuliwan]

Thank you very much!
We can't solve our cross-compilation proble. So we decide to develop in C++ .

[niuliwan]

I'm sure I'm going to run into a lot of problems and need your help.

[alexpevzner]

ipp-usb is the HTTP proxy, first of all. So the first thing to consider, what are you plan to make HTTP level from.

Go has excellent HTTP implementation on its standard library. If you plan to use C++, my advise is to start from choosing HTTP library for C++,

[alexpevzner]

HTTP proxy consist from the HTTP server, HTTP client and some glue code between them.

In the HTTP library, the server part is the first thing to consider. In the ipp-usb I've ended up with the library HTTP server and home-made HTTP client (made from the library-provided parts, though). The standard, library-provided HTTP client was good enough from its functionality point of view, but not transparent enough for troubleshooting purposes.

The important thing to consider, HTTP library must allow to deal with big attachment in the streaming mode. Go HTTP library simple returns document body as io.Reader, and program may read from there as much as it can handle.

Prefetching entire document into the memory may consume a lot of memory, because typical document is the image sent to printer or received from scanner.

[alexpevzner]

Another important thing, ipp-usb comes with collection of "quirks" - workarounds for firmware bugs of some printers. Quirks are defined by collection of INI-style configuration files, located in the /usr/share/ipp-usb/quirks and documented in the ipp-usb man page.

There are no hidden quirks in the ipp-usb code, all are defined by these quirks files.

I suggest you to use these quirk files "as is", it will allow you in the future to import new quirks from the ipp-usb, as soon as they arrive.

[niuliwan]

Thank you ,I am reading your code,It's great.
I see we are listening on port 6000.But How did they know to send a request to port 6000? Did the Avahi do something?

[alexpevzner]

Yes. ipp-usb advertises via Avahi the presence of the IPP printer and the eSCL scanner at the localhost:60000 address (and under different HTTP path)

In short, DNS-SD (known also ad MDNS, Bonjour etc) is the service that allows somebody to advertise something to the entire local network, and interested parties can find it, using decentralized protocol without dedicated server. And the same mechanism works within the single machine, using localhost addresses. On Linux, this infrastructure is implemented with a help of Avahi daemon

Under the hood, it uses DNS messages, distributed using UDP milticasts.

BTW, what OS are you porting to?

Goolge at ChromeOS uses UNIX-domain socket instead. I have no idea how do they deal if 2 or more printers connected, but we can ask @yetamrra

[niuliwan]

OpenHarmony

[alexpevzner]

Is it a kind of Linux, or it uses its own kernel?

[yetamrra]

On ChromeOS, we start up copies of ippusb_bridge with udev when a device is connected. It creates one socket per connected printer. For enumeration of locally-connected IPP-USB printers, we use libusb to enumerate all the devices and then look up the correct local socket path for each device by VID:PID.

If you wanted to reuse ippusb_bridge on OpenHarmony, you will need a rust toolchain, libusb, some mechanism to start ippusb_bridge when a USB device is attached (udev or whatever equivalent OpenHarmony uses), and an HTTP library that can send requests through UNIX domain sockets. In general, I think it's likely that ipp-usb is a better choice, since it's more feature complete and uses more standardized interfaces.

[niuliwan]

Is it a kind of Linux

Is a kind of Linux,but a lot of things have been simplified.

[alexpevzner]

If it is a kind of Linux, even simplified, Go must work there with a reasonable effort

[niuliwan]

I'd love to reuse ipp-usb but the problem with compiler Go language is almost impossible to solve.

[niuliwan]

I have a few questions:
1) What does the printer need to do somethings, do they only need to support ipp printing and USB Protocol?
2)Did we just forward the entire HTTP request data to the printer?
3) After all, this is not the data listened on a TCP port.How does the printer know that it is an HTTP request after reading data from the USB?

[alexpevzner]

Hi @niuliwan,

I'd love to reuse ipp-usb but the problem with compiler Go language is almost impossible to solve.

Honestly, it sounds a bit strange. Pure Go program can run on a top of bare Linux kernel without any external libs. ipp-usb uses few external libraries (most important are, libusb and libavahi-client.so.3). libusb will be required even for your C++ version, so you will have something to solve issues with its presence, if these issues exist. Avahi is required for signalling. If you invent some alternative signaling mechanism, in theory, ipp-usb can be ported to use it.

1. What does the printer need to do somethings, do they only need to support ipp printing and USB Protocol?

Printer needs to provide USB interfaces with Class=7, Subclass=1, Protocol=4. These and only these interfaces do support IPP over USB protocol. Not all USB printers and scanners support this protocol, but newest ones tend to support.

So, ipp-usb is not the universal solution that works with all and any USB printer. But there is a very noticeable and growing class of devices that will work with it (thanks to Apple who presses hardware vendors to support IPP over USB in their devices).

Did we just forward the entire HTTP request data to the printer?

Actually, much more: https://github.com/OpenPrinting/ipp-usb#under-the-hood

The most important thing: ipp-usb "sanitizes" HTTP requests. Regardless of client's behaviour, printer always receives valid HTTP transactions.

After all, this is not the data listened on a TCP port.How does the printer know that it is an HTTP request after reading data from the USB?

Because 7/1/4 USB interfaces expect to receive HTTP requests and return HTTP responses.

[niuliwan]

Thank you very much for your kind help!
Based on your experience, what is the approximate percentage of printers that support this 7/1/4 USB interfaces?

[alexpevzner]

Very hard to say, because people mostly come to me with problems, not with success stories.

In the long-term perspective - 100%.

[zdohnal]

@alexpevzner Alex, what do you think of having a table of successful devices with IPP-over-USB, the same way as the table for sane-airscan?

[alexpevzner]

Hi @zdohnal,

I've missed the chance to start gathering this table from the very beginning. So currently this is unlikely that we will be able to collect a representative table.

From another hand, sane-airscan is device enabler, from the user perspective. ipp-usb, if it works, is almost invisible to the end users. And as now it comes by default with many distros, many users may even don't suspect that they actually use this daemon.

@tillkamppeter and @michaelrsweet think that all modern device come with IPP-USB support, and all new network devices come with the eSCL support as well. I'm not as optimistic as they are, but supporting IPP-USB and eSCL opens the door to the Apple's users market, so I expect that in the long-term perspective (i.e., in few years) literally all new devices will support these protocols.