I'm looking for an X11 server on the iPhone to be able to use the NX protocol. There are RDP clients, Citrix clients, VNC clients, but no X11 server...
Do you think it is possible to port (or create ?) an X11 server (by example kdrive modified for Cocoa) for the iPhone? Does it have enough CPU-power or memory for that? How would you do that? Are there alternatives?
It certainly has enough CPU power and memory - X11 has been running on < 10mhz machines since it's inception. Of course, these didn't support blending, anti-aliasing, shape extensions, etc. Clocking in at 600mhz+ and a modern graphics chip, the iPhone is a smoking monster machine.
Zingersoft though provides, as Rob Napier said, an X server, so obviously must be possible :)
First you should take a look at Zingersoft. Your second step will probably be working to get XQuartz compiling for iPhone.
Yes, it's possible. Whether it makes sense or not is a different matter - X is not only the drawing protocol, it's the interaction model as well. You'd be hard-pushed to do right-clicks, control-characters or most other operations that X programs will want to do.
Frankly, you're probably better off hosting a VNC session onto a remote X session held by a run of the mill Linux box rather than going down this road if all you want to get is bits on the screen.
Related
We need to do some stress testing of our system, and we would like to be able to simulate non-ideal situations: things like latency, jitter, etc. In particular, we would like to simulate behavior of data over a cellular network.
Do you know of any hardware/software/both solutions that would work?
Thanks
Ideally you would get some idea about parametrization from a real simulator like ns3. Or write one yourself.
Additionally you could use the Linux kernels built-in QoS stack which provides the netem module which can be used for these purposes. netem provides network emulation functionality for testing protocols by emulating the properties of wide area networks. The current version emulates variable delay (jitter), loss, packet corruption, duplication and re-ordering. It supports distribution based opteration or you could script it to change certain values during run time.
Wifi card with an older access point/router, simply take the test station to the edge of the range and you should be able to reliably cause the connection to fail and reconnect. Only reason I sugest an older model is that the range generally weren't that fantastic on the older "802.11b" stuff.
But other than just being a lossy connection, I am not sure you'd be able to use this setup to test certain characteristics of a cellular connection, but it should work.
If you are in the US, an iPhone on AT&T would probably do it..
Probably need something along the lines of:
USRP Board, OpenBTS, TrixBox/Asterisk
You can check out OpenBTS(http://openbts.sourceforge.net/) and see if it will do what you need. You could have it use the USRP board as a tower, then use it similar to a loopback. I do know that the above combination will allow phones to connect to it like a cell tower(See BurningMan/DEFCON 18), so in theory it should allow you to broadcast out to saturate the spectrum.
OpenBTS-UMTS include 3G data http://openbts.org/w/index.php?title=OpenBTS-UMTS
You can download and compile on Ubuntu 16.04, there is some issue with dependencies on Ubuntu 18.04.
About hardware, i used both Ettus USRP N210 and X310.
I'm writing some Perl code. I want it to run on Windows and Linux/UNIX/OSX. So far it works on *NIX and uses fifos.
I am considering switching to sockets to avoid the problem that POSIX::mkfifo() doesn't work on Windows, so I need to write some separate code to use Win32::Pipe.
I'm feeling ambivalent about the whole thing. It seems to me both fixes require about the same amount of work. Is it a good idea to switch to sockets?
Short answer: IO::Socket::INET works on both Windows and *NIX.
Named Pipes
Slightly easier to code up quickly. You don't need write connect code.
Slightly faster. Sockets have the overhead of TCP and setting up the initial connection.
Works on all platforms.
Works even when network card doesn't exist. Some laptops shut down the network card to save power which can prevent even local sockets from working.
Sockets
Works on all platforms. However, some laptops shut down the network card to save power and even local sockets won't work if there is no network interface.
More portable in Perl. IO::Socket::INET works on both *NIX and Windows.
Allows you to have a separate conversation with each client.
Firewalls are not a problem. Ports over 1024 should work.
Personally, I've decided to switch to sockets. In my application it doesn't matter much. But I think it makes the code a bit simpler, gives me the flexibility to move to > 1 client in the future, and I want to learn IO::Socket anyway.
Answering more generically (ie, it's not perl specific):
Doing this sort of thing in windows vs the rest of the world almost always requires separate code for windows vs everything-else. Pretty much everything-else has good solutions for things like this, like unix file sockets or fifo's or ... Then on windows you have to fall back to sockets.
The right thing to do, IMHO, is to use the right solution on windows that isn't network sockets because that opens the application up to security issues. So on everything else "do it correctly" but then on windows, fall back to something like network sockets instead. But, make sure if you take the network-socket route you should at least use local sockets only (ie, bound to 127.0.0.1).
For perl, I'd be tempted to look in CPAN for a class that's already made this generic. But... I wouldn't be surprised if nothing exists.
LWP::socket works fine in Windows and *NIX. If you opt for sockets over fifos, then you eventually would be able to communicate Windows and *NIX processes. May be you don't need it today, but who knows.
IIRC, later versions of Perl have a working socketpair on Windows.
I want to make a Wi-Fi controlled robot.
After a lot of research, I decided to use an Asynclab's BlackWidow which was the best way for me to do this.
But unfortunately, this product is out of stock everywhere!
I ordered one on roboshop and I got the message 25 days later: Sorry, this product is sold out.
So, I'm looking for another microcontroller with a Wi-Fi interface.
I also need this very quickly (because it is for a school project), and it must be as cheap as possible.
I've been looking all the day but I couldn't find something as "good" as the BlackWidow.
You can get the WiFly shield from sparkfun.
In the past I have used a Linux router (with positive results) with Gargoyle (OpenWrt based) as a wireless gateway and communicate with it through a serial port, as most of them attach a console to the serial port so that you just have to send the command and '\n' to be executed. With the cURL libraries should be fairly easy to communicate without much effort with whatever you want.
You have the power of Linux and a pretty powerful CPU, can configure it through the command line or web page, and most important, a lot of routers are much cheaper than the 'BlackWidow'.
The one I used is the Fonera+ (unmounted doesn't take much more space than an Ethernet Shield) and used to cost around $28 although it is now deprecated, but some other routers from Linksys, TP-Link, etc. are also compatible as stated in the OpenWrt Compatibility Table.
I want to write a program from scratch to see the sockets activity, what they send, what they receive, etc. I don't want to use a Library because it's more for academic purposes than anything else.
Where should I start?
Just to be clear: my program won't be connecting to anything or creating any socket, it just wants to listen to the activity in a computer.
Any thoughts (in any OS) about where to start will be appreciated.
Thanks in advance.
Take a look at libpcap/WinPcap.
You are out of luck as far as portability goes.
Although the application APIs are the same or similar for UNIX and Windows, and, both implementations are historically based on the same Berkeley Sockets BSD code, the operating system architecture and hence the ways you access low level OS functions such as network IO are completely different.
Linux has a number of 'network sniffing' tools(tcpdump, ethereal etc.) easily available. Not so sure about windows, MS provides a Network Monitor and there are some tools available -- Google 'Sysinternals TDImon' for the MS tools.
As part of a client support tool, I'm wanting to provide some functionality to be able to request to view/remote control a desktop session. There are a bunch of ways to get a screen capture and then stream it, but I'm wanting to find out in particular, why the RDP (Remote Desktop / Terminal Services vs. VNC experience is so different. I'm using RDP vs. VNC just because they seem to use drastically different methods to stream the screen to the client.
If I had to guess, RDP appears to transmit blocks of bitmap graphics (say 100x100px) in order to build the full picture (which can be quite slow) but seems to transfer normal painted shapes/fills, or font drawing to the client extremely quickly. VNC seems to take giant snapshots of the screen, compare a previous image and stream the changes to the client.
I feel that RDP is a much more high-quality and smooth protocol than anything else out there, so what technique does it use to accomplish this?
EDIT-Just to clarify, I am asking about these graphics techniques specifically as a streaming protocol programming method - not for which existing product/technology to use to solve this business requirement.
As you found out, they are both pretty different in the way they stream change.
The RDP protocol from MS is and extension of a ITU standard (T.128) that can be purchased online.
RDP implements lots of bandwidth-saving techniques that complement each-other and make it very efficient over low bandwidth.
VNC on the other hand has very basic compression techniques: it will send blocks of bitmap that have changed and will use basic types of compression, from RLE to jpeg to transmit those blocks efficiently.
Unfortunately, it's still quite wasteful over low bandwidth.
VNC basically has no knowledge of the underlying graphic primitives used to build the screen. That makes it easy to use on any machine because it just monitors changes to the screen bitmap.
RDP on the other hand hooks deeper into the Windows API and is able to optimize its stream based on the minimum amount of information necessary to generate the same update on the client.
If you want to integrate remote desktop functionalities, you have a couple of choices:
for RDP you may use the ActiveX used for web remote functionalities. You may want to have a look at a wrapper to integrate it into your own software.
If you want to get deeper into this there is source code available for the linux rdesktop client that does connect to Windows machines across RDP.
for VNC there are a number of open source implementations.
FogCreek's Copilot actually uses one and you can get its source as it is built on TightVNC
There are also a number of projects on CodeProject on RDP and VNC.
As Renaud said, VNC simply sends over bitmap changes block by block without any knowledge of what the content is. RDP is much smarter.
You can check out exactly what RDP does from these two specs:
Protocol level:
http://msdn.microsoft.com/en-us/library/cc240445(PROT.10).aspx
Graphics level:
http://msdn.microsoft.com/en-us/library/cc241537(PROT.10).aspx
I think RDP's biggest gains come from:
Caching: The client can store a large amount of previously seen blocks and the server can tell the client how to use them. Also these are persistant so when a client connects to a server it's already been to it can advertise what blocks it has on disk. Very useful when windows get moved. Also many parts of windows, like the title bar are the same.
Line/Block drawing. As you guessed RDP has operations for line, poly and rect drawing. With drawing windows these come in use quite a lot.
Font drawing. RDP has a way to send over gylphs for fonts and tell the client to render them.
Cursor rendering. The cursor icons are sent as glyphs. VNC simply uses a dot
Those are the big ones that come to mind. Check out section 2.2.7 Capability Sets of the protocol spec for the complete list of drawing features.