Android X server(my20percent.wordpress.com)
my20percent.wordpress.com
Android X server
http://my20percent.wordpress.com/2012/02/27/android-x-server/
10 comments
> I had assumed that all internet-enabled smartphones would be sitting behind NAT-ing routers, both for security reasons and to conserve IPv4 addresses. But no, on the “3″ network in Australia at least, phones all have externally-accessible IP addresses, meaning they can run servers.
This seems like a terrible thing.
Given that data costs so much on phones, you would think just the internet background noise would cost quite a lot per month.
http://en.wikipedia.org/wiki/Internet_background_noise
According to that article the background noise is about 20 bits per second. According to my back of the envolope calculation that is about 6.1 megabytes per month.
I get around 50 megabytes per $6 on my phone so this is costing me 73c per month!
This seems like a terrible thing.
Given that data costs so much on phones, you would think just the internet background noise would cost quite a lot per month.
http://en.wikipedia.org/wiki/Internet_background_noise
According to that article the background noise is about 20 bits per second. According to my back of the envolope calculation that is about 6.1 megabytes per month.
I get around 50 megabytes per $6 on my phone so this is costing me 73c per month!
Arguing for NAT in order to compensate for a broken billing model is a terrible idea. :)
Saunalahti in Finland also have publicly routed 3G. I wish this were far more common, it feels very 22nd century to effortlessly ssh to the phone in your pocket, even if the capability existed since the 20th. Such a shame contemporary networks are usually so brain damaged
Saunalahti in Finland also have publicly routed 3G. I wish this were far more common, it feels very 22nd century to effortlessly ssh to the phone in your pocket, even if the capability existed since the 20th. Such a shame contemporary networks are usually so brain damaged
Broken billing model is anything but flatrate? Hardly practical in practice for such a scarce resource. Noone wants to pay for that, it can only exist as an option where few will use it.
How about denial of service attacks? I could easily kill your battery and drain your quota for the month with a few keystrokes - and there's not much you can do about it.
Yes, I prefer NAT for my mobile connections. Just use a VPN if you want external access.
How about denial of service attacks? I could easily kill your battery and drain your quota for the month with a few keystrokes - and there's not much you can do about it.
Yes, I prefer NAT for my mobile connections. Just use a VPN if you want external access.
Not sure how you arrived at flat rate being the only alternative. It's almost trivial to count ingress only for host flows to which the customer's device responds positively (say, by replying using anything except ICMP or a TCP error)
I wouldn't call it trivial - you'd need a stateful firewall (not necessarily a NAT) to keep track of which network flows are active. It would also be exploitable - you could open a TCP control connection to host X, and have host Y stream you data over UDP, to which you never reply directly, but rather use the host X control connection to ack the data.
Does any ISP do that though? I've never heard of it, then again I haven't had contact with any ISP delivering external IPs to mobile connections.
The point about battery remains though. And the solution you propose can easily be exploited to allow unlimited data for say, video streaming.
The point about battery remains though. And the solution you propose can easily be exploited to allow unlimited data for say, video streaming.
In Saunalahti's case they differentiate by offering different connection speeds, all at flat rate. I'm not really sure if what I suggested is implemented anywhere, just playing devil's advocate. :) One possible solution might be to combine it with stateful filtering, dropping a unidirectional ingress flow after some number of packets if the device never responds. My point was mainly that something must be broken if the customer is getting billed due to the environment beyond their control.
In the case of power management I'm not sure it's that simple, it's at least true that the HTC Dream would not usually respond to pings while the display was off (haven't experimented with other devices). Presumably the application processor only awoke when a kernel timer fires, which only applies to client sockets the device itself created. Actually it makes sense that random inbound data traffic wouldn't wake the phone, otherwise you risk your OS getting a bad reputation because of some crappy telcos sending ARP every 1 second or something.
In the case of power management I'm not sure it's that simple, it's at least true that the HTC Dream would not usually respond to pings while the display was off (haven't experimented with other devices). Presumably the application processor only awoke when a kernel timer fires, which only applies to client sockets the device itself created. Actually it makes sense that random inbound data traffic wouldn't wake the phone, otherwise you risk your OS getting a bad reputation because of some crappy telcos sending ARP every 1 second or something.
I agree that it is unreasonable, and is a bit shocked that there are countries where receiving an sms can cost you money... But a reasonable solution to incoming data is to enable NAT, it isn't much of a hinder for a tech savvy user and is otherwise better for the 99.99% of the users.
My phone (Nexus S) always responds to the pings I send. Which kind of makes sense, the default is to have a constant connection to google anyway (so that it can receive any push messages). Apparently google already made the decision that it is worth the battery drain. And android has already gotten plenty of bad reputation for applications misbehaving. While I'm sure some telcos are misbehaving in all ways imaginable as well it is probably nothing compared to the apps users gladly install for themselves.
My phone (Nexus S) always responds to the pings I send. Which kind of makes sense, the default is to have a constant connection to google anyway (so that it can receive any push messages). Apparently google already made the decision that it is worth the battery drain. And android has already gotten plenty of bad reputation for applications misbehaving. While I'm sure some telcos are misbehaving in all ways imaginable as well it is probably nothing compared to the apps users gladly install for themselves.
> something must be broken if the customer is getting billed due to the environment beyond their control.
This is what happens when you debate random tangential topics online while hung over.. so basically I had no point to make, and you made me realize NAT is a pragmatic solution to the imaginary problem I'm complaining about.
> Presumably the application processor only awoke when a kernel timer fires
And of course for the reasons you point out, this presumption was obvious nonsense. :) Now I'm not sure what caused the behaviour I saw on the Dream.
This is what happens when you debate random tangential topics online while hung over.. so basically I had no point to make, and you made me realize NAT is a pragmatic solution to the imaginary problem I'm complaining about.
> Presumably the application processor only awoke when a kernel timer fires
And of course for the reasons you point out, this presumption was obvious nonsense. :) Now I'm not sure what caused the behaviour I saw on the Dream.
Some of us in the US still have unlimited data plans. Not many, but some of us were grandfathered into it and hold onto it for dear life :)
Not exactly related to your post, but I'm not sure why he would be concerned with the phone service's NAT if the x-window app is running on a remote server (making him the client). Now if he were running it on his phone (as the server) and connecting to it through the cellular data service, then I could see why.
Not exactly related to your post, but I'm not sure why he would be concerned with the phone service's NAT if the x-window app is running on a remote server (making him the client). Now if he were running it on his phone (as the server) and connecting to it through the cellular data service, then I could see why.
X windows client server model can seem intuitively backwards. The applications you run on remote servers are clients of the x server (that renders the windows) you are running locally.
It's a relic from a different era: You had a dumb terminal that could only display stuff, and several servers that each could run a piece of software you like.
Also, the networks were (supposedly) less dangerous security wise, so people worried less about things like authentication and access control back then.
X is celebrating 25 years or so these days: And yet, modern clients can mostly work with 25 year old clients, and modern servers can definitely accept connections from 25 year old clients. And it's very usable.
It's a marvel of engineering, even if it is showing its age.
Also, the networks were (supposedly) less dangerous security wise, so people worried less about things like authentication and access control back then.
X is celebrating 25 years or so these days: And yet, modern clients can mostly work with 25 year old clients, and modern servers can definitely accept connections from 25 year old clients. And it's very usable.
It's a marvel of engineering, even if it is showing its age.
Still, it'd be a good idea to tunnel it through an outbound SSH connection (which is generally the preferred method of starting up the X client app in the first place).
Some providers give you the choice, and let you choose if you want unfiltered access or firewalled, just by changing APN. For some services, like a backup link to your internal network, it's immensely useful.
I would be more concerned about battery usage than data costs.
More Android<->(non-android)Linux compatibility would be great. Given that the linux desktop is moving toward wayland, and given that android's SurfaceFlinger is a lot closer to wayland than to X, I'm not sure that X is the best way forward. It would be interesting to see how much work it would take to implement SurfaceFlinger apis in terms of wayland or vice versa.
Kind of like this work implementing the AudioFlinger api on top of pulseaudio: http://arunraghavan.net/2012/04/pulseaudio-on-android-part-2...
Kind of like this work implementing the AudioFlinger api on top of pulseaudio: http://arunraghavan.net/2012/04/pulseaudio-on-android-part-2...
So is this the first real X client on Android? I've only found VNC clients for Android in the past. Having a real X client would be amazing because that would allow the efficient use of GUIs with a chroot install of debian (or pick-your-distro)! The status quo is to use a VNC server in the chroot and a VNC client on Android to get a GUI. Not very "clean".
I'm not convinced this would be good for much as it is, considering the reality of input devices on Android, but it seems like something like this could have potential in aiding porting. Getting a good terminal emulator ported to Android using this sort of thing to help could be an interesting endeavor for example.
Android has fantastic support for mice, touchpads and keyboards (not to mention Xbox 360 controllers, etc).
In practice nobody actually uses those things. The reality of input on android is that the general public just uses touch screens.
The set of people willing to use a mouse with their phone is probably a strict superset of those who want to run X, so I wouldn't think of it as problematic.
Also, good on the OP. But X on Android? It's a jfb Hell.
Also, good on the OP. But X on Android? It's a jfb Hell.
"nobody"? Asus Transformers are a very popular option for Android tablets, in part because they have keyboards and touchpads and a full sized USB port for easily plugging in mice.
What I really want is to extend my host's desktop onto the Android device. I'd settle for something as simple as Synergy working (in the wishlist, not done yet).
There are numerous solutions for Windows and Mac (eg AirDisplay, SplashTop) but nothing to extend Linux desktops onto Android devices.
There are numerous solutions for Windows and Mac (eg AirDisplay, SplashTop) but nothing to extend Linux desktops onto Android devices.
Both GTK+ (broardway) and Qt (lighthouse) have some sort of HTML5 frontend. It is the most portable solution, if not a little slow. Extending the desktop can be done with some VNC+Xinerama trickery too. But it ain't easy, I will give you that. If you want to drag and drop a window from Xorg to Android (2 server), get ready for trouble. Not that X can't support it, it does, but modern toolkit hate being redirected like that, it is a very niche X11 feature.
In other words not particularly practical :-)
I would expect the tablet to be plugged in as a virtual monitor (ie xrandr would should it as another monitor) and if you take the tablet away it should be no different than disconnecting a monitor.
I would expect the tablet to be plugged in as a virtual monitor (ie xrandr would should it as another monitor) and if you take the tablet away it should be no different than disconnecting a monitor.
Cool. Since android has great VPN capabilites being NATed doesn't necessarily present any problems.
EDIT: And why not link to the play store? https://play.google.com/store/apps/details?id=au.com.darksid...
EDIT: And why not link to the play store? https://play.google.com/store/apps/details?id=au.com.darksid...
FWIW iSSH on iOS has good X support.
This is cool hack, but is there anything fun or useful I could do with it?
Running X UI Toolkits on Android like Tcl/Tk, GTK, QT, Java/swing, Inferno/Tk, etc.
I might enjoy running a full X IDE and other tools on my powerful dev box from my phone.
I wonder whatever happened to the NX projects... they were optimizing X11 for high-latency systems.
I wonder whatever happened to the NX projects... they were optimizing X11 for high-latency systems.
[deleted]
I did something similar, but ported the C X server to Android using the JNI.
If you want to compare approaches my source is at http://github.com/tmzt/androix and a test apk is available at http://db.tt/UkFlvNAm