Handling multiple connections
andreas at kostyrka.org
Tue May 1 23:10:43 CEST 2007
Sorry for the long reply time.
-) IMHO, MMS+WAP despite everything one might think, do have uses, and
basically all phones do support. Actually WAP is an unloved but still
used platform for all kinds of stuff.
-) using multiple APNs (and that basically implies concurrent
connections) are needed, because some WAP services (like payment
services) work only via the internal network of the network provider.
-) Yes, your implementation suggestions are certainly better than my
* Harald Welte <laforge at openmoko.org> [070429 09:23]:
> On Sat, Apr 28, 2007 at 08:48:26PM +0200, Andreas Kostyrka wrote:
> > Just wondering, how do we currently plan to handle multiple data
> > connections. I've got the impression that this hasn't been given much
> > of a thought.
> this is more or less true, at least that thought is under flux and will
> certainly not be documented before there is any code, leading to more
> vaporware ;)
Good idea. The hardware feels already vapor-like to many people. ;)
> We seriously have tons of more important issues right now. As soon as
> the higher priority issues have been implemented, we can always think of
> more advanced features and look on their implementation.
> > a) multiple APNs: Internet, MMS, other apps (guess we won't get a
> > blackberry client that fast, but still it might happen)
> well, so far this is not on our list of requirements. so far, we do not
> intend to support MMS or WAP, e.g.
*) Both features (WAP/MMS) are standard features of a GSM phone. The
only phones that come to mind that don't have these are phones
designed especially for "people that don't want the complexity, that
want a phone that allows them to talk". No idea how the market
perception will be if Openmoko misses such features.
*) There are markets where MMS are at least partially sucessful.
Receiving MMS is a standard feature, worse, people expect
(herearounds, and well, young people) that one can read MMS. And are
incredibly offended when one ignores them. (And yes, my Treo that I
used at that time did not receive MMS.)
*) I can understand about WAP, but as much it pains me, there
are applications for this <censormode> %$§%$"$§ </censormode>.
Mobile ticketing for the German railways. Btw, it needs both MMS and
*) Some network operators like to make extra cash by selling
"multimedia" like ringtones. These usually are managed via WAP too.
Just some thoughts.
> > b) VPNs.
> how does that related to a more or less physical connection? Also,
> there are many technologies (openvpn, ipsec, vtun, cipe, to name a few)
> and they all have their own properties and ideas on how to express
> > c) CSD dialup connections.
> What I think is actually more important and missing from your list :
> d) bluetooth BNEP
> e) usb ethernet emulation
Yes, I was thinking more about the framework/software implications.
The observations I wanted to mention:
*) mobile device != stationarly TCP/IP host.
*) concurrent different paths are needed.
Just a scenario:
I've been text chatting while sitting in the subway, and somebody
mentions an URL I want to visit. Now I want to look up that URL.
Luckily, I just arrived home, so I have an accesspoint (be it USB,
Bluetooth or WLAN) for high speed access.
Now if the device does not support concurrent paths, either I need to
surf the web via a GPRS (4-5KB/s connection), or I need to interrupt
my chat session and reconnect via the accesspoint.
Before you say anything, this is just a scenario that is seldom say
with a laptop, because most people power down their laptop. I once did
it (office -> GPRS -> DSL), and the same problems ensue here. (I did
it, because I considered it important that I catch somebody online ;) )
> > The important property here is, that openmoko needs to understand
> > first of all that there are different destinations: e.g. Internet, MMS
> > service, private networks (via CSD, via VPN).
> who needs to understand that? libmokonet and the preferences app needs
> to understand it, true. but the applications certainly not.
Well, most applications not. Some applications might want to
understand it, e.g. a MMS client.
> oh, you want to do per-application based policy routing? that's
> certainly a non-trivial task to do. Nothing that I think openmoko would
> be able to look into for at least the next six months.
It's not trivial. Adding it later makes it only slightly harder.
> > We should intercept connect() and show a dialog, probably defaulting
> > to "Internet" destinations.
> no, that is ugly and would resemble the idea of personal firewalls.
> which network packets to route to where, and which connections to accept
> and which not is the job of the kernel network stack. We have _tons_ of
> tools to do stateful packet filtering, policy routing, traffic shaping,
> and combinations thereof (e.g. you can do stateful routing, selecting a
> route at connection startup time).
Yes. Sorry for my offensive implementation ideas. I just wanted to
sketch some solution to the problem. Actually, it was the first idea
how to implement it came to me.
> > We should provide an openmoke_connect_tcp_socket(...) function in the
> > API, where the app can finetune which connection properties it needs.
> > (It might even go so far: "I need a long running connection", "I need
> > a connection with maximum bandwidth", ...)
> I don't think the applications should care about this. This is
> non-standard and diverges way too much from the usual way how tcp/ip and
> sockets work.
Yes. OTOH, a mobile device that has multiple network devices
"builtin", is not the usual device. The usual TCP/IP host does have
a default route, and that's it.
> Somehow, the user-defined preferences/policies need to be translated in
> policy routing and packet filtering configuration. This policy is
> always present, and does not require any special application support.
> If you want to interactively permit/route/... connections, then this
> will most likely need to be done via NFQUEUE mechanisms. You can QUEUE
> all packets that connection tracking deems NEW, and then return a
> verdict into the kernel. I believe this is how e.g. the NuFW personal
> firewall handles this.
Agreed, as I said, I provided one possible way to do the tracking as
illustration that it's possible and not necessarily that complicated.
> Thus, I argue that any such connection policy implementation
> a) does not depend on explicit application support but works with all
> existing applications, without modifying them, system libraries or
> kernel code
> b) uses existing infrastructure such as iproute2/tc/iptables/NFQUEUE
> c) uses files in the filesystem to specify the policies
> d) will have some userspace management daemon and/or control programs
> storing the policies.
> e) application packages (ipk's) just provide a policy file with the
> default policy
> > This can be implemented by patching the upstream libc,
> sorry, but: over my dead body.
I cannot even claim that I wrote the mail after midnight :(
More information about the openmoko-devel