Difference between RDP/Terminal Services and VNC Streaming Techniques

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.

From stackoverflow

• 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%28PROT.10%29.aspx

  Graphics level: http://msdn.microsoft.com/en-us/library/cc241537%28PROT.10%29.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.

SPARC - Bit mask without shift

Hi, I'm learning SPARC assembly and I have to create a script that extracts a field from a register. The script accepts 3 values, initial number, field start position, field length.
It can't use any shift functions, but it can use multiply and divide.
I'm currently suffering from a respiratory virus, and am subsequently on a significant amount of drugs. I'm having a lot of difficulty figuring out where to even start on this. Some direction would be greatly appreciated.

From stackoverflow

• Multiply by 2 is a left-shift and divide by 2 is a right shift (at least for unsigned numbers).

  If you want to left shift by 2 bits, that's a multiply by 4.

  So, for example, if you have the binary value:

  b15              b0
  v                 V
  0000 1111 0101 1000
  

  and you wanted to extract b3 and b2, you would AND the whole lot with 0xc0 and divide by 4.

  0000 1111 0101 1000
  0000 0000 0000 1100  <- AND with 0xc0
  -------------------
  0000 0000 0000 1000
  -------------------
  0000 0000 0000 0010  <- divide by 4
  

  Since this sounds suspiciously like homework (and I haven't coded for SPARC for a long time), I won't attempt to give you a finished solution - that should be enough to get you going.

  derrickp : Thanks! Yeah, I should have made it more clear; I was only looking for direction not a solution. This should be perfect, I'll see what I can do.

Mindset difference between workstation and embedded programmers

What do you think are the difference in mindset between a programmer doing work for a desktop environment (windows, linux, whatever...) and someone doing work on an embedded system?

A simple example I can think of is that in an embedded environment, I always check that a malloc is not NULL. Most code I have seen that target desktops is certainly not diligent in checking malloc return value.

Any other examples of mindset differences?

From stackoverflow

• I desktop environment there's the idea that "hey I can always release an update or patch to fix this later." In embedded design, you get more "this has to work cause we don't want to recall the device or release an even longer patching program."

  Michael Burr : Although the ability to issue firmware updates is moving the embedded world into a mindset closer to the desktop one more and more over time...

  Suroot : Agreed, we can see this with new EEPROMs and the ability to release flash updates. As seen on motherboards for years and we'll probably be seeing on graphics cards soon. You can now program your own shaders which get applied to the gfx card now.

• size matters

• 2 things - as Suroot already mentioned, once you release a desktop app, it doesn't have to be "forever", especially nowadays.

  But in embedded, once you "ship it", it's on its way to Mars so you're not going to be able to pull it back.

  Also one of the major differences are that embedded programmers are generally a LOT more conscious about efficient code and memory management - desktops run horrible code really fast, embedded doesn't.

  JeffV : I think they actually did a firmware update on the Mars rovers.

  routeNpingme : I bet that's what you would call an "intense" moment while it restarts... ;)

• Desktop programmers view resources as practically unlimited. Memory, computing power, drive space. Those never run out. Embedded programmers focus intently on all of those.

  Oh, and embedded programmers also often have to worry about memory alignment issues. Desktop coders don't. The Arm chips care. x86 chips don't.

  JeffV : Can you elaborate on the : "The Arm chips care. x86 chips don't."

  Steve Rowe : Sure. Most non-x86 CPUs like the ARM that is so popular in embedded systems will only read an integer if it is on a DWORD (32-bit) boundary. They will fault if asked to read a non-aligned int. The x86 will happily read such an int, it will just be a little slow.

• Funny that you mention malloc() specifically in your example.

  In every hard-real-time, deeply embedded system that I've worked on, memory allocation is managed specially (usually not the heap, but fixed memory pools or something similar)... and also, whenever possible, all memory allocation is done up-front during initialization. This is surprisingly easier than most people would believe.

  malloc() is vulnerable to fragmentation, is non-deterministic, and doesn't discrminate between memory types. With memory pools, you can have pools that are located/pulling from super fast SRAM, fast DRAM, battery-backed RAM (I've seen it), etc...

  There are a hundred other issues (in answer to your original question), but memory allocation is a big one.

  Also:

  • Respect for / knowledge of the hardware platform
  • Not automatically asssuming the hardware is perfect or even functional
  • Awareness of certain language apects & features (e.g., exceptions in C++) that can cause things to go sideways quickly
  • Awareness of CPU loading and memory utilization
  • Awareness of interrupts, pre-emption, and the implications on shared data (where absolutely necessary -- the less shared data, the better)
  • Most embedded systems are data/event driven, as opposed to polled; there are exceptions of course
  • Most embedded developers are pretty comfortable with the concept of state machines and stateful behavior/modeling
  Crashworks : malloc() considered harmful?

Graphical code analysis

I'm using SubVersion in conjunction with Hudson, and I like the feature that shows the how the unit tests, build time, disk usage grow over time. I'm a believer in code metrics to get a first cut appraisal of a code base - especially useful when starting with a new client. Are there any tools that can do the following

1) Starting from Date/Tag get every revision of the Source Code

2) Build it

3) Run code analysis

4) Run tests

5) Store detailed results (in Sql database of somekind)

6) Repeat until no more revisions

7) Collate and present the results

You can see a summary output for hudson itself, but that gives no idea of individual files, and how they have changed over time.

From stackoverflow

• Have a look at Sonar http://sonar.codehaus.org. I have used this using maven for my Java project. It reports most of the features you looking for.

How to get the path of the context directory in jsp and how can i overwrite it for every new request..

Hi i am getting path of the context directory in my local system using..

String myfile = application.getRealPath("/");

but the method getRealPath("/") is returning null when application is deployed in war file in www.eatj.com.. can any one provide me possible solution and sample code please... The purpose is i have to create a xml file in my context directory... and each request i have to overwrite this xml file...

From stackoverflow

• This is what Javadoc says

  Returns a String containing the real path for a given virtual path. For example, the path "/index.html" returns the absolute file path on the server's filesystem would be served by a request for "http://host/contextPath/index.html", where contextPath is the context path of this ServletContext..

  The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive).

Good protocol for FAST inter-application communication?

I am about to implement a server application that can answer queries fast. The server is implemented in java. I don't want to waste a lot of time on a complicated communication protocol so I search for a good best-practice way of 1) performing a query to my server 2) letting the server answer that query Both the queries and answers will be maps from integers to integer lists.

Related: Are there any combined framework that both handles the query/response protocol AND manage incoming queries (puts them in a queue)?

I don't know if I should implement it as a plain daemon or a web service. A web service seems more flexible as it can be relatively easily moved to another machine but a plain daemon sounds faster.

From stackoverflow

• I know this is kind of a general answer, but you're talking a difference of milliseconds between a daemon and a web service.

  With that said, go with the more flexible architecture. Good design will FAR outweigh the technology you use to execute it.

  If a couple milliseconds really counts, then the question is not which technology to use but how you can use caching and load balancing to scale it.

• You could follow the leader and user HTTP for that :)

  For instance in their AJAX API, they use it in conjunction with JSON ( or is it plain javascript ? )

  Here is an example.

  For the following query:

  http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=hello%20world&langpair=en%7Cit&callback=foo&context=bar
  

  The complete output is this:

  HTTP/1.0 200 OK
  Date: Thu, 12 Feb 2009 05:13:31 GMT
  Content-Length: 97
  Content-Type: text/javascript; charset=utf-8
  Expires: Thu, 12 Feb 2009 05:13:31 GMT
  Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  Pragma: no-cache
  X-Backend-Content-Length: 16
  X-Embedded-Status: 200
  X-Content-Type-Options: nosniff
  Server: GFE/2.0
  
  {"responseData": {"translatedText":"ciao mondo"}, "responseDetails": null, "responseStatus": 200}
  

  Of course the test is very simple, but using java the implementation could not be simpler that that.

  Of course it depends on your project needs, security, access control etc, but by using HTTP you can relay on a super tested protocol.

• If performance is that much of an issue I suspect you well need to go for some kind of grid of cluster solution. I wrote an overview of Java grid/cluster libraries awhile back that is useful background.

  If commercial software is an option I'd suggest looking at GigaSpaces (or some freeware JavaSpaces implementation if not). It'll allow you to do:

  • FIFO ordering of messages, if that's important to you (although that comes with a performance cost);
  • Sub-millisecond transactional grid updates;
  • It comes with a JMS implementation built on top if you want to use that queueing API; and
  • Messages are defined by class so you can just read/write the appropriate operations.

  GigaSpaces (and any serious grid/clustering technology really) scales well. Much better than a pure queueing solution, which either doesn't scale with publish-subscribe (since all listeners receive a message; not typically what you want) or request-response (where you have to make sure the queue isn't blocked by a bad message).

  You don't mention what technology the server is using. If it's Java then you're OK. If not it gets a little more interesting. If that is the case you may want to consider building something using Google Protocol Buffers, which is a high-performance binary interchange format and is supported on Java, C++ and possibly other platforms.

  Personally I'm not a huge fan of Web services because they're not transactional (in the sense that they can't enrol in distributed transactions). That may or may not be an issue for you. Plus interoperability between different technology stacks (eg Java and .Net) is still problematic at best.

• If you develop a daemon server, what interface you are providing clients to connect? You would be implementing sockets or RMI or something else. Not a very flexible and easy to maintain solution when it comes to scalability.

  Go with webservice.

  Bhushan : Webservice is a broad term for me. It means anything provided over http. You can certainly create a servlet and deploy your application in say Tomcat. Now clients can access your application via that servlet by passing parameters. Your servlet can return response in XML or text depends what you want

• A daemon will be faster in the short term at the price of flexibility. The advantage of the daemon is that you can just send the reply back in a compact form, in your case as a stream of binary integer values. This will be as fast as you can get.

  If the number of requests increases beyond a certain limit, you can use DNS with Round Robin to spread the load over several machines, so there is no advantage of using a HTTP server.

  The main drawback is that you can't debug this interface easily (with most Internet protocols, you can just telnet to the port on which the server listens and run a couple of commands and see the result). Also, if you have to change the interface for any reason, you will have to change every client as well. This gets worse when you need to use this service somewhere else, for example in a mashup.

  So if you want to be more flexible, use a protocol like HTTP and JSON as the data format. This is not as compact as the binary, so answer times will be worse. How much worse depends on the size of the data. If you can fit the JSON encoded response into a standard IP package (about 1500 bytes), you probably won't notice the difference.

• unless you have tried multiple methods, you wont know which one is "better". The best way is to prototype each, and try it! it doesnt even have to do all you want to do, just do the basic bits (like returning predefined data), and you can load test it to see which one is better.

  i suspect that these days, modern machines will perform fast enough for http to work reasonably well, and with the added benefit of being more standardized, other services can take advantage of your server without needing a specialized client.

Which is the best book to start Java ME?

I am looking for a book to start programing using Java Platform, Micro Edition (Java ME). Which book will you recommend to a reader who knows Java and have some knowledge of Java EE? Thanks everyone in advance.

From stackoverflow

• J2ME game programming is the book that I have enjoyed most over the years (Y)

  /JaanusSiim

  Fostah : I agree with book. This is the book I learned with as well.

  Agusti-N : Yes it's a good book.

• Beginning J2ME: From Novice to Professional, (2005) Third Edition by Sing Li and Jonathan Knudsen

  Enterprise J2ME: Developing Mobile Java Applications (2003) by Michael Juntao Yuan

  J2ME: The Complete Reference(2003) by James Keogh

  J2me in a Nutshell (2002) by Kim Topley

  They are all good books, but they are dated. I can't think of a recent decent J2ME title. The Nutshell is really good, I don't understand why there isn't a 2nd edition. The demand is there. Take note of the authors though, some of them post articles here and there that are more current (and free).

  You can find some good tutorials at Netbeans if you poke around there. Check out the articles section at developers.sun.com. There are plenty of articles on specific tasks. You might want to download j2mewtk, here is an article on that by none other than Knudsen. There are some good sample programs, with source code to play with, that come with the j2mewtk.

  Important things to know when starting out with J2ME: The difference between CLDC (for low-end phones -limited to J2ME api's) and CDC (for smartphones -uses both J2ME and J2SE api's (not the current version -1.4.2 (I think) with no depreciated api's)).

  With J2ME there are a lot of things you can't do, like access system files, or the phones inbox. You also can't make/log phone calls. The gui is pretty limited too, unless you use CDC or perhaps a third party tool.

• Netbeans offers a variety of tutorials on Java ME.

  This Blog offers numerous books, which you can use for training youself in Java ME. Good Luck!