Todo For This Week
- Send multiple usb packets worth of server response to client
- Refactor everything to be better
Completed This Week
- Multiple usb packets sent to client
- Many functions refactored, thank you to Eric Fiselier (https://github.com/EricWF) for valuable help
- Support content-length http messages
- Support transport-encoding chunked messages
- Rename project to IPPUSBXD
Todo Next Week
- Rewrite USB and TCP to not need knowledge of message size
- Book flight and hotel for OpenPrinting Summit
This Monday I got content-length messages supported. Which was fantastic news to present on Tuesday’s OpenPrinting conference call. Earlier on the weekend I noticed Mac OSX’s version of ippusbd was also called ippusbd. I mentioned this and Ira suggested renaming my ippusbd to ippusbxd.
So now I’m working on ippusbxd! I like the new name, it looks pretty good on the logo:
Also on the conference call I mentioned the “only” feature left to implement was supporting chunked transport http messages.
I was wrong.
Just today I landed chunked transport support upon which this greeted me in my browser:
Ha! This is a major set back! HTTPS wraps the entire HTTP messages in encryption. Thus preventing us from knowing the HTTP message’s size. In the current architecture this in turn prevents us from know when to stop asking for more data. If we went as far as integrating OpenSSL or a similar we could make a half-solution and man-in-the-middle attack the SSL connection, which would not be pretty.
Instead I’ll have to rewrite a decent chunk of the HTTP handling to not need the message size. We can avoid attacking the SSL connection and simplify the code if instead of using blocking TCP receives calls we use non-blocking calls. This lets us ferry data between the client and the server without worrying if any data is even coming from the client or the server.
This will require some strategic sleep()s to prevent 100% CPU usage but should work well in practice.
The other option could be to ask HP to disable HTTPS since ipp over usb requests never hit the internet. I like having everything encrypted so I’m glad this option is avoidable.
Still looking back this does mean all of the week’s work will be redone. The driver will be better for the rework. The codebase will be smaller and safer. So I’m not sad about the lost effort, plus it gives me something to mention at the OpenPrinting Summit.
In fact unless I knew ahead of time we needed HTTPS I might still think inspecting the HTTP for the message size was the best solution as it provides lower latency.