Common reply to Rick and Mike-
These are both great comments. When I take this feedback and put it in context of 15 years of doing this remote computing stuff, I am seeing a covergange up head. i.e. A total device that is at once the Net2Display “decoder” and a thin client and a rich PC. That is, a solid state device that has the intelligence of low level network optimization, remote display client and local decoders/media clients as well as a Calista like client/graphics server.
With practical solid state drives just around the corner, perhaps the new thing will really be all the old things wrapped up into one smart device. It is all solid state and seamlessly mixes local execution with remote displays-- when you walk up, login or put in your tiny 2TB solid state key, it becomes everything you need on the fly. Let’s say you have LAN connectivity, then everything is remoted. Let’s say you have mediocre WAN, it caches and downloads those elements that can’t run well interactively. Let’s say that you are on a high bandwidth but high latency connection like satellite or across the planet on a WAN, then it would actually stream a virtual machine down to the local device to run and the files you need…..
To guide this powerful solid state device we would need an open format to communicate the conditions and requirements of each element of the session, something like XML for remoting, i.e. XDL- Extensible Display Language, a way of telling the device you are sitting exactly how to handle each application, rich media stream, voice conversation, remote machine, virtual machines, etc..
Just dreaming out loud, but it makes sense to me!!
Steve Greenberg
Thin Client Computing
34522 N.
(602) 432-8649
steveg@thinclient.net
From: thin-bounce@freelists.org [mailto:thin-bounce@freelists.org] On Behalf Of Mike Hancock
Sent: Sunday, June 08, 2008 9:56 AM
To: thin@freelists.org
Subject: [THIN] Re: Pano VDI Solution
Couldn’t companies like Citrix move more of the intelligence down the stack and into the networking layers by leveraging existing products like WANscaler instead of depending on the client device for the buffering? In theory, a PC, thin client or whatever, and any software on those devices should never have to know if it is getting data from a LAN or a WAN.
I know Cisco is moving toward taking the WAN and emulating a LAN with more intelligent networking, prioritization, security and caching and pitting it onto their routers and switches.
Just a thought
Mike
From: thin-bounce@freelists.org [mailto:thin-bounce@freelists.org] On Behalf Of Rick Mack
Sent: Sunday, June 08, 2008 6:25 AM
To: thin@freelists.org
Subject: [THIN] Re: Pano VDI Solution
Hi Steve,
The Net2Display standard is real and is set to be ratified later this year. Considering IBM's contribution to Net2Display I don't think I'd lose any money on a bet that they'll be one of the first implementers, but initially for blade PCs only. On the thin client front, Devon IT might very well be first out of the blocks and considering the relations between VMware and Microsoft, it wouldn't be all that surprising to see Net2Display support in VDM3.
I guess I've got to qualify my comments with regards to Net2Display and RDP/ICA because life is never totally simple.
If we think about what Panologic and Teradic are doing at the moment then it's likely that we will have no operating system as such on the Net2Display thin client devices, at least for LAN-connected devices (see comments about WAN below). That's pretty profound and will mean that we will finally have thin client devices are much less expensive than a PC with no compromises in the area of graphics, USB support and multimedia. Imagine what that will do for thin client-based technologies in education.
I think that Net2Display will be the killer protocol for LAN conencted thin clients and will very likely displace RDP and
If we have a look at
The only way to handle multimedia redirection effectively is by redirecting the multimedia content to the appropriate player on a thin client device with enough buffereing to deal with bandwidth variability. That unfortunately results in increasing the complexity of the operating system at the client end with a multitude of codecs, players and IE plugins. If you've got embedded XP or XP/Vista running on all your thin client machines just to support multimedia, at least some of the promised TCO savings compared to managing traditional fat clients get swallowed up managing the thin client device operating systems.
The challenge for the Net2Display protocol is that playing multimedia content on the thin client device is still the most efficient way to do it in terms of bandwidth utilization even with stuff like lossy compression. That doesn't matter on a LAN or where you've got lots of bandwidth, but it does matter on a high-latency and slow or variable bandwidth WAN connections.
We also haven't addressed latency effects that need stuff like a local text echo, local cursor, additional TCP/IP optimization and so on to make an acceptable user experience. That's going to require somewhat more intelligence at the thin client end and means that at the least we will need a minimal latency-aware operating system that supports multimedia players.
So for WAN connected thin clients, Net2Display probably isn't going to provide the functionality needed unless it's a piece of client software running on an operating system that supports multimedia redirection and all the other latency reduction stuff. That sounds a lot like what we've got already with
I'd better finish rambling now with a bit of a summary.
Net2Display has a very good chance of dominating the LAN-connected thin client market. While I'm not discounting the effects of the Callista technology on RDP, Microsoft is going to have to do something really interesting on the thin client o.s. licensing side to make RDP competitive in that area.
The outcome in the WAN connectivity area is still wide open. Provision Network's enhanced RDP is catching up with
regards,
Rick
--
Ulrich Mack
Quest Software
Provision Networks Division
No comments:
Post a Comment