Giving IP access over VFAT using intelligent USB device

[Ole Tange]

I have thought a little on how to give IP-access to the Neo using a
cybercafe PC that can only read/write the VFAT on the Neo.


Giving IP access over VFAT using intelligent USB device.

Background: Today you can walk into a cybercafe and connect your USB
stick to a PC. Often you cannot install software on the PC, but you
can access the VFAT filesystem on the USB with a browser.

I will here examine if it is possible to give the USB stick HTTP access
provided the USB stick is highly intelligent.

Basic idea:
>From the PC upload a file from the USB stick to a special webserver.
The file is on the USB stick in VFAT format and is generated on the
fly. The file contains a PPP stream wrapped in some padding. The
server will unwrap the PPP stream and give IP access using PPP.

>From the PC download a file from the special webserver to the USB
stick. The file on the webserver is generated on the fly and contains
reply to a PPP session wrapped in some padding.

USB --> wrapped PPP-stream --> PC --> Webserver
USB <-- PC <-- wrapped PPP-reply <-- Webserver

Problems:
* USB cannot create a blocking file (e.g. a pipe) that only sends data
when needed.
  This is impossible as the PC may not understand pipes and if a
requested datablock is not delivered a timeout may occur. The USB must
therefore deliver a datablock when requested.

* How do we make sure data continues to flow without having a huge overhead?
  This problem can be split into 2 problems: The flow from server via
PC to USB and the flow from USB via PC to server. The problem depends
on how the PC caches data:

  USB -> PC_cache1 -> Server
  USB <- PC_cache2 <- Server

   We should assume that we do not know how big the caches are and how
they are flushed as that will give a solution that would work on most
systems - even including proxies and firewalls.

   The server can force the PC to flush PC_cache2 by sending a lot of
NOOP data. These can be deflated so they will not take up a lot of
network bandwidth.

   To flush PC_cache1 the server must accept a lot of data generated by
the USB. If data is requested of the USB, but the USB has no data to
send, it should generate NOOP data.

   To reliably send a message from server to USB the server will send
the message to PC. This is followed by a flush of PC_cache2. When the
message is received by USB, USB will acknowledge the message. So the
server should continue to flush PC_cache1 and PC_cache2 until it has
received the acknowledgement.

   To reliably send a message from USB to the server the USB must
piggyback its message on an acknowlegement or a NOOP. The server will
therefore have to make sure there is a constant stream of data to
piggy back on. Preferably the round trip time of the stream should be
around a second.

  To minimize the bandwidth used from the USB to the server, the
server should throttle the incoming data if they only consists of
NOOPs for more than one roundtrip. It should, however, not throttle so
much that a timeout occurs.


/Ole