Wednesday Oct 03, 2007

More Display Protocol FUD

CLAIM: Only raw bitmap changes are sent, not drawing commands such as used by RDP, ICA and X Windows protocols. Like VNC, "SLIM" is a very simple protocol to implement on the client, however it typically uses far more bandwidth than protocols that use drawing primitives and is more prone to screen damage.


Windows-based terminals that the competition sell employ either the Citrix ICA protocol or the Microsoft RDP protocol to communicate with a server running Windows Terminal Server. These protocols are quite similar in nature to X but are tied to the Windows GUI API (ICA to a lesser extent than RDP). On the other hand, the low-level Sun Ray protocol has no such bias and can be used by a system with any rendering API. Another difference between them and the Sun Ray protocol is that they are highly optimized for low-bandwidth connections.  This is accomplished via a variety of techniques, including Windows object-specific compression strategies (run-length coding of bitmaps), caching of Windows objects and state at the terminal, and maintaining backing store at the terminal.  Because the resources included in the terminals directly determine the performance and bandwidth savings possible, these types of systems can have expensive terminals which constantly require upgrades to improve performance.   Consider that last sentence for a moment.  If it is not true, then why do the competition offer so many different models with varying amounts of RAM, CPU's, graphics cards, flash storage, and operating systems?

Sun Ray interprets the ALP rendering commands into a local frame buffer which drives the raster refresh to the display.  Original ALP rendering commands were set pixel, fill rectangle with solid color, expand bitmap, expand transparent bitmap, copy screen area, and color space convert/scale YUV pixels to RGB pixels.  Call me silly, but those seem like "drawing commands" to me.  Since the release of SRSS 1.0, there have been a number of other rendering commands added such as LC and DWT for Low Bandwidth and Zero Width Line Fills/Fill List of Spans for local rendering (what the competition calls primitives).  The Sun Ray protocol also has features for dropped and out of order packets, screen damage protection so these claims by competitors are not only unwarranted, they are plain wrong.

You can view an older blog entry comparing and contrasting ALP and ICA here.  The beautiful thing is when they are used together, it's the best bandwidth scenario of all! 

Tuesday Oct 02, 2007

Display Protocol FUD

CLAIM:  The contents of the virtual frame buffer get sent to the Sun Ray client using Sun’s proprietary “SLIM” protocol, which is somewhat similar to the open-source VNC protocol.

The competition is clearly reading  white papers from 1999 and picking low hanging fruit since  “SLIM” was a name chosen while trademarks and patents were being completed for the Appliance Link Protocol (ALP).  Would it be fair to compare the competitions thin client offerings or protocol support from 1999?  We choose not to do so since it's highly unethical, not to mention embarrassing for them.  Sun Ray has always had 24 bit color, CD quality audio, bi-directional audio and could play 30 Frames per second with ShowMeTV and MPEG-2 movies.  

Comparing ALP to VNC on one hand is a compliment as both are protocols which is independent of any operating system, windowing  system, and application.  A key difference between the two approaches is the manner in which the display is updated.  With the Sun Ray protocol, updates are transmitted from the server to the consoles as they occur in response to application activity. VNC, on the other hand, uses a client-demand approach. Depending on available bandwidth, the VNC viewer periodically requests the current state of the frame buffer. The server responds by transmitting all the pixels that have changed since the last request. This helps the system scale to various bandwidth levels, but has the drawback of larger demands on the server in the form of either maintaining complex state or calculating a large delta between frame buffer states.

Most people in the server based computing industry have used VNC and while most would agree it is an interesting technology that fills many needs, most will also agree that their experience with the VNC protocol is that even in low-latency, high-bandwidth environments VNC is sluggish at best and not a good solution for a thin client protocol. Thus the competitions comparison of ALP to VNC and calling them “somewhat similar” is done to invoke thoughts of sluggish performance, no device access, no multimedia features.  Further complicated by a connection process of having launching the VNC server and then telling the VNC client which server instance and port number to connect to.

About

Think Thin is a collection of bloggers that work with Oracle's Virtual Desktop portfolio of products.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today