Monday, November 29, 2010
Following on from this post I'm now adding new longer status updates as new posts.
The design of Baps has meant that the current implementation is mostly transparent and does not know about any of the underlying data being sent, contrasted with Hiisi which re-interpreted each http request. The benefit to my approach this is that there is less likely to be an error on my part in resending any type of data onwards, however the difficulty lies in that I still need to establish the destination addresses, ports and length from the data, but I don't have easy access to this information (technically I'm using raw sockets to send bytes rather than a http connection and APIs which could do this for me). This approach has led to delays such as working out content length resulting in "chunked" data and HTTP 1.0 data not being sent correctly (thankfully HTTP 1.0 is not too common and both have an easyish fix but I digress).
I've already started thinking about bluetooth drop out protection but this will be quite difficult to get right (the whole system needs to freeze immediately until the connection is re-established meaning existing requests and results are queued) or else the browser will not receive the results. For this reason it unlikely to be perfect or even in the first release.
Friday, November 12, 2010
PROGRESS UPDATE 4 17/03/11:
Work has stopped until I have some significantly free time. HTTP errors and traffic timeouts are causing the main problems and will require a lot more than a few hours of an evening which my other projects take, especially to make it easy for Joe User to install and configure. This is the next project on my todo list but I have a lot of other pressing things I need to deal with over the next 6-8 months. Sorry.
PROGRESS UPDATE 3 27/11/10:
Success! The proxy on both sides is very fast and very minimal. I'm now fixing transfer length issues (HTTP 1.0 support), need to add disconnection protection as well as a decent configuration UI, installer and do some code cleaning and QA. Multiple app connections are possible but data is sent via a single synchronous link to the Baps server (on Windows), i.e. both sides process multiple requests at the same time but data is ordered again for sending between the phone and PC.
PROGRESS UPDATE 2 25/11/10:
End to end transmission is almost complete, I'm having some minor trouble with the data passed back to the phone (and displayed by the proxy on the phone during testing) actually being passed back to the calling app and numerous requests at once going out of sync but this is something I know how to fix :)
PROGRESS UPDATE 19/11/10:
I can now send a single preformatted HTTP request from the phone to the PC and receive a response on the phone (admittedly the reponse is usually a HTTP 301 or 400 error probably caused by incorrect request packet formatting). This is taking longer than I anticipated especially as I have a busy weekend coming up and it is still very much proof of concept (no gui or configuration yet). I'm re-estimating *at least* another 2 weekends.
ORIGINAL TEXT FOLLOWS:
So I've purchased a Nokia 5230 which is a fine touch screen phone and has a built in GPS. The only problem is that it has no WIFI so all net access is charged at premium 3G rates even when I'm at home and have broadband.
I'm now working on a proxy along the lines of the Hiisi Suite and MiniBTProxy called "Baps" (Bluetooth Access Point Service) that will allow an Internet connection over Bluetooth for Nokia mobile phones using Microsoft Windows XP/Vista/7 with a broadband connection.
I've already implemented a simple proxy on Windows and will shortly be adding Bluetooth functionality to it courtesy of the Marge Bluetooth API.
The goals of this mini project are to:
- Make it easy to install (installer and guide).
- Proxy only HTTP (no secure HTTPS connections).
- Support multiple connections (allowing many mobile apps to run at once - a problem for the existing Bluetooth proxies).
- Provide seamless as possible connection restoring functionality in the event of Bluetooth dropout.
Optional long run goals are:
- Improve mobile device compatibility.
- Add Linux server support.
- Improve performance.
As usual source code will also be made available on release sometime before or around the 21st of November.