List Processor Results.
vnc-list-digest@uk.research.att.com
vnc-list-digest "at" uk.research.att.com
Mon, 01 Mar 1999 22:55:00 +0000
1:
2:
3: vnc-list-digest Monday, March 1 1999 Volume 01 : Number 245
Unknown command: vnc-list-digest
4:
5:
6:
7: .............................
Unknown command: .............................
8: VNC-LIST-DIGEST is a daily collection of the messages sent to the
Unknown command: VNC-LIST-DIGEST
9: VNC mailing list. For more information about VNC see the home page
Unknown command: VNC
10: http://www.uk.research.att.com/vnc .
Unknown command: http://www.uk.research.att.com/
11:
12: In this issue:
Unknown command: In
13:
14: Basic Question
Unknown command: Basic
15: Re: Basic Question
Unknown command: Re:
16: Re: The need for RFB option negotiation (DO, DON'T, WILL, WON'T)
Unknown command: Re:
17: GEOS vnc?
Unknown command: GEOS
18: vnc seg. faults
Unknown command: vnc
19: RE: Cannot get vncserver to work on RH Linux 5.2
Unknown command: RE:
20: Re: The need for RFB option negotiation (DO, DON'T, WILL, WON'T)
Unknown command: Re:
21: .............................
Unknown command: .............................
22:
23: ----------------------------------------------------------------------
Unknown command: -------------------------------
24:
25: Date: Sun, 28 Feb 1999 02:24:03 -0500
Unknown command: Date:
26: From: "Duncan Kinder" <dckinder "at" hgo.net>
Unknown command: From:
27: Subject: Basic Question
Unknown command: Subject:
28:
29: I have about the most basic question one can ask.
Unknown command: I
30:
31: Am I correct in my belief that one not only can, for example, view, say a
Unknown command: Am
32: Linux or a Mac screen from within, say, a Windows screen but also that one
Unknown command: Linux
33: can acutally manipulate the Linux or Mac programs that one views?
Unknown command: can
34:
35: Duncan C. Kinder
Unknown command: Duncan
36: dckinder "at" hgo.net
Unknown command: dckinder "at" hgo.net
37:
38:
39: - ---------------------------------------------------------------------
Unknown command: -
40: The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
Unknown command: The
41: - ---------------------------------------------------------------------
Unknown command: -
42:
43: ------------------------------
Unknown command: ------------------------------
44:
45: Date: Sun, 28 Feb 1999 10:21:40 +0000
Unknown command: Date:
46: From: Simon Dick <simond "at" irrelevant.org>
Unknown command: From:
47: Subject: Re: Basic Question
Unknown command: Subject:
48:
49: On Sun, Feb 28, 1999 at 02:24:03AM -0500, Duncan Kinder wrote:
Unknown command: On
50: > I have about the most basic question one can ask.
Unknown command: >
51: >
Unknown command: >
52: > Am I correct in my belief that one not only can, for example, view, say a
Unknown command: >
53: > Linux or a Mac screen from within, say, a Windows screen but also that one
Unknown command: >
54: > can acutally manipulate the Linux or Mac programs that one views?
Unknown command: >
55:
56: Yes :)
Unknown command: Yes
57:
58: - --
Unknown command: -
59: Simon Dick simond "at" irrelevant.org
Unknown command: Simon
60: My views most definitely don't reflect those of any employer I may have
Unknown command: My
61:
62: - ---------------------------------------------------------------------
Unknown command: -
63: The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
Unknown command: The
64: - ---------------------------------------------------------------------
Unknown command: -
65:
66: ------------------------------
Unknown command: ------------------------------
67:
68: Date: Sun, 28 Feb 1999 10:23:15 -0000
Unknown command: Date:
69: From: "John Wilson" <tug "at" wilson.co.uk>
Unknown command: From:
70: Subject: Re: The need for RFB option negotiation (DO, DON'T, WILL, WON'T)
Unknown command: Subject:
71:
72: - ----- Original Message -----
Unknown command: -
73: From: W. Brian Blevins <brian "at" tridia.com>
Unknown command: From:
74: To: <vnc-list "at" uk.research.att.com>
Unknown command: To:
75: Cc: W. Brian Blevins <brian "at" tridia.com>; Christof Ullwer
Unknown command: Cc:
76: <Christof.Ullwer "at" cmcc.com>; John Jarrett <john "at" tridia.com>
Unknown command: <Christof.Ullwer "at" cmcc.com>;
77: Sent: 27 February 1999 16:42
Unknown command: Sent:
78: Subject: The need for RFB option negotiation (DO, DON'T, WILL, WON'T)
Unknown command: Subject:
79:
80:
81: >
Unknown command: >
82: >Quentin and the AT&T VNC Group,
Unknown command: >Quentin
83: >
Unknown command: >
84: >The post at the end of this email indicates to me that there will
Unknown command: >The
85: >eventually be multiple independent VNC implementations. I doubt
Unknown command: >eventually
86: >Mr. John Hazen is the only person to have made this observation.
Unknown command: >Mr.
87: >
Unknown command: >
88:
89: <snip>
Unknown command: <snip>
90:
91: I hve independantly implemented both ends of the VNC protocol (VncMonitor &
Unknown command: I
92: VncProxy) and I am currently designing a protocol wrapper to allow mutiple
Unknown command: VncProxy)
93: connection mutiplexing across an optionaly encrypted optionally compressed
Unknown command: connection
94: link with strong authetication. In addition I am beging to design a VNC
Unknown command: link
95: server which is a telent client and which uses the existing VNC protocol to
Unknown command: server
96: send character based screen updates to a client (i.e. the VNC "sceen" is 24
Unknown command: send
97: X 80 "pixels" where each "pixel" is a character plus display attributes). S
Unknown command: X
98: I migh have some insight into the stregths and weaknesses of the existing
Unknown command: I
99: protocol.
Unknown command: protocol.
100:
101: Firstly, the existing protocol already allows the following things to be
Unknown command: Firstly,
102: negotiated:
Unknown command: negotiated:
103: the protocol version
Unknown command: the
104: the authentication scheme
Unknown command: the
105: the frame buffer update encoding
Unknown command: the
106: desktop sharing
Unknown command: desktop
107: the number of bits per pixel and the pixel encoding
Unknown command: the
108:
109: Secondly, the issues of stream multiplexing, encryption, compression, strong
Unknown command: Secondly,
110: authentication, HTTP tunnelling, reverse connection, etc are probably better
Unknown command: authentication,
111: handled by a protocol wrapper layer than an extension to the VNC protocol
Unknown command: handled
112: (people happliy use SSH to achive much of this at the moment and I'm pretty
Unknown command: (people
113: sure SSL could be used transparantly). Feature negotiaition is then a matter
Unknown command: sure
114: for the wrapper protocol not the VNC protocol.
Unknown command: for
115:
116: However, there are a number of areas in the existing protocol that I have
Unknown command: However,
117: found awkward:
Unknown command: found
118:
119: Protocol version negotiation:
Unknown command: Protocol
120: the precise way in which this should take place is unclear from the
Unknown command: the
121: protocol spec. I do think that the client could give a list of protocol
Unknown command: protocol
122: versions in preference order and the server should be required to chose one
Unknown command: versions
123: it can support fully or offer a list of its own.
Unknown command: it
124:
125: Initial Handshaking Messages
Unknown command: Initial
126: it is most unfortunate that these massages do not have message type
Unknown command: it
127: codes. This requires a proxy to be statefull and (at least in my design)
Unknown command: codes.
128: causes the client message handling code to be consideably more complex than
Unknown command: causes
129: is needed.
Unknown command: is
130:
131: Frame Buffer Update
Unknown command: Frame
132: there is n way of parsing this message whithout knowing the number of
Unknown command: there
133: bits per pixel. The number of bits per pixel is not encoded in the message
Unknown command: bits
134: (although there is space). You can construct a scenario wher the client
Unknown command: (although
135: recieves one of these messages and is uncertain of the number of bits per
Unknown command: recieves
136: pixel ised by the server - basically this is a bug in the protocol.
Unknown command: pixel
137:
138: John Wilson
Unknown command: John
139: The Wilson Partnership
Unknown command: The
140: 5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
Unknown command: 5
141: +44 1296 641072, +44 976 611010(mobile), +44 1296 641874(fax)
Unknown command: +44
142: Mailto: tug "at" wilson.co.uk
Unknown command: Mailto:
143:
144:
145:
146: - ---------------------------------------------------------------------
Unknown command: -
147: The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
Unknown command: The
148: - ---------------------------------------------------------------------
Unknown command: -
149:
150: ------------------------------
Unknown command: ------------------------------
151:
152: Date: Sun, 28 Feb 1999 12:09:15 +0000 (GMT)
Unknown command: Date:
153: From: Darrell Berry <darrellb "at" hhcl.com>
Unknown command: From:
154: Subject: GEOS vnc?
Unknown command: Subject:
155:
156: i remember awhile ago someone had done a GEOS port of an earlier version,
Unknown command: i
157: but i can't find it anywhere...can anyone help?
Unknown command: but
158:
159: thnx
Unknown command: thnx
160:
161:
162: - ---------------------------------------------------------------------
Unknown command: -
163: The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
Unknown command: The
164: - ---------------------------------------------------------------------
Unknown command: -
165:
166: ------------------------------
Unknown command: ------------------------------
167:
168: Date: Sun, 28 Feb 1999 10:28:18 -0600
Unknown command: Date:
169: From: "Lance Heller" <mephisto "at" unidial.com>
Unknown command: From:
170: Subject: vnc seg. faults
Unknown command: Subject:
171:
172: I've installed vnc-3.3.2r3 from source on my S.u.S.E. 5.3 linux 2.0.35
Unknown command: I've
173: machine and vnc-3.3.2r6_x86-win32 on a Win95 box. Unfortunately the
Unknown command: machine
174: vnc-client running on my linux box will segmentation fault anytime
Unknown command: vnc-client
175: an attempt is made to access a menu item from the taskbar of the
Unknown command: an
176: server W95 system. Also, when viewed from linux the W95 icons are
Unknown command: server
177: often mostly obscured by black rectangular sections.
Unknown command: often
178:
179: The W95 box runs 256 colors while the linux box is 24bit on a 4mb
Unknown command: The
180: Matrox Millennium card. On the linux side I've tried both the binary
Unknown command: Matrox
181: vnc distribution and have built the lot from source, with the same
Unknown command: vnc
182: result in both cases.
Unknown command: result
183:
184: Any help or suggestions you may have will be greatly appreciated.
Unknown command: Any
185:
186: Thanks.
Unknown command: Thanks.
187:
188: Lance
Unknown command: Lance
189:
190:
191:
192:
193: - ----------------------------------------------------------------------
Unknown command: -
194: Lance Heller email: lheller "at" unidial.com
Unknown command: Lance
195: - ----------------------------------------------------------------------
Unknown command: -
196:
197:
198:
199:
200:
201: - ---------------------------------------------------------------------
Unknown command: -
202: The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
Unknown command: The
203: - ---------------------------------------------------------------------
Unknown command: -
204:
205: ------------------------------
Unknown command: ------------------------------
206:
207: Date: Mon, 1 Mar 1999 00:33:46 +0100
Unknown command: Date:
208: From: Arjan Rodenburg <amr "at" fatal-error.net>
Unknown command: From:
209: Subject: RE: Cannot get vncserver to work on RH Linux 5.2
Unknown command: Subject:
210:
211: Hi,
Unknown command: Hi,
212:
213: At first, I hope this msg is HTML less. I had to disable it both in my
Unknown command: At
214: Outlook
Unknown command: Outlook
215: and in the Exchange server. If not, pls don't flame, just warn :-)
Unknown command: and
216:
217: Yes, I did delete the # by accident (vi is not really forgiving).
Unknown command: Yes,
218: Second: to get it to work I DLded the Linux 5.2 RPM like Duncan
Unknown command: Second:
219: suggested and after playing around a bit I found that I only needed the
Unknown command: suggested
220: vncserver part of this package.
Unknown command: vncserver
221:
222: Lots of thanks for the help. VNC is running like sunshine now. ANd cross
Unknown command: Lots
223: platform
Unknown command: platform
224: (W95, w98, Winnt40 Server and Linux RH 5.2)
Unknown command: (W95,
225:
226: Cu,
Unknown command: Cu,
227:
228: Arjan Rodenburg
Unknown command: Arjan
229:
230: > -----Original Message-----
Unknown command: >
231: > From: Quentin Stafford-Fraser [mailto:quentin "at" uk.research.att.com]
Unknown command: >
232: > Sent: Saturday, February 27, 1999 6:04 PM
Unknown command: >
233: > To: vnc-list "at" uk.research.att.com
Unknown command: >
234: > Subject: Re: Cannot get vncserver to work on RH Linux 5.2
Unknown command: >
235: >
Unknown command: >
236: >
Unknown command: >
237: > Arjan Rodenburg wrote:
Unknown command: >
238: >
Unknown command: >
239: > > However, perl IS in usr/bin
Unknown command: >
240: > > the first line of the vncserver script reads
Unknown command: >
241: > > !/usr/bin/perl
Unknown command: >
242: >
Unknown command: >
243: > Are you sure? It should be '#! /usr/bin/perl'. Did you
Unknown command: >
244: > delete the # by
Unknown command: >
245: > accident?
Unknown command: >
246: > I get similar messages to yours if I delete the #.
Unknown command: >
247: >
Unknown command: >
248: > Quentin
Unknown command: >
249: > ----------------
Unknown command: >
250: > Dr Quentin Stafford-Fraser
Unknown command: >
251: > AT&T Laboratories Cambridge
Unknown command: >
252: > http://www.uk.research.att.com/~qsf
Unknown command: >
253: >
Unknown command: >
254: >
Unknown command: >
255: >
Unknown command: >
256: > ---------------------------------------------------------------------
Unknown command: >
257: > The VNC mailing list - see
Unknown command: >
258: > http://www.uk.research.att.com/vnc/intouch.html
Unknown command: >
259: >
Unknown command: >
260: > ---------------------------------------------------------------------
Unknown command: >
261: >
Unknown command: >
262:
263: - ---------------------------------------------------------------------
Unknown command: -
264: The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
Unknown command: The
265: - ---------------------------------------------------------------------
Unknown command: -
266:
267: ------------------------------
Unknown command: ------------------------------
268:
269: Date: Sun, 28 Feb 1999 20:04:19 -0500 (EST)
Unknown command: Date:
270: From: Kenneth Albanowski <kjahds "at" kjahds.com>
Unknown command: From:
271: Subject: Re: The need for RFB option negotiation (DO, DON'T, WILL, WON'T)
Unknown command: Subject:
272:
273: On Sat, 27 Feb 1999, W. Brian Blevins wrote:
Unknown command: On
274:
275: >
Unknown command: >
276: > Quentin and the AT&T VNC Group,
Unknown command: >
277: >
Unknown command: >
278: > The post at the end of this email indicates to me that there will
Unknown command: >
279: > eventually be multiple independent VNC implementations. I doubt
Unknown command: >
280: > Mr. John Hazen is the only person to have made this observation.
Unknown command: >
281: >
Unknown command: >
282: > Given that it seems very likely there will be multiple independent
Unknown command: >
283: > VNC implementations (a true sign of protocol excellence), should one
Unknown command: >
284: > not strive to provide for option negotiation in the same way that
Unknown command: >
285: > the TELNET protocol does? TELNET is a truly flexible and
Unknown command: >
286: > cross-platform protocol. As I see it, VNC is very much architected
Unknown command: >
287: > in the same fasion.
Unknown command: >
288: [...]
Unknown command: [...]
289:
290: I'm afraid I have to agree with Alan here. First of all, telnet is an
Unknown command: I'm
291: asynchronous character stream protocol, as opposed to a synchronous packet
Unknown command: asynchronous
292: protocol (which is how I'd describe VNC). Furthermore, I have in fact
Unknown command: protocol
293: written a TELNET server, and my advice would be that the DO/DONT/WILL/WONT
Unknown command: written
294: metaphor is extremely fragile in practice and theory, that TELNET is a
Unknown command: metaphor
295: miserable example in any case, and that I would not recommend the set of
Unknown command: miserable
296: techniques popularlized by TELNET to _anyone_, for any purpose.
Unknown command: techniques
297:
298: > To me, the option negotiation in TELNET is primarily responsible for
Unknown command: >
299: > allowing widely divergent client and server implementations to
Unknown command: >
300: > sucessfully interoperate. Is that not the grand plan for VNC?
Unknown command: >
301:
302: "Divergant implementations" and "sccessfully interoperate" are the two key
Unknown command: "Divergant
303: phrases here, and I think you'll find neither is quite as true as you
Unknown command: phrases
304: assume. As I said, I've written my own TELNET server: I started out with
Unknown command: assume.
305: my own code, based on the RFCs, and found that a perfectly compatible
Unknown command: my
306: implementation was impossible in any reasonable amount of time. I ended up
Unknown command: implementation
307: simply porting the common BSD code. The result is "successful
Unknown command: simply
308: interoperation", but a completely non-divergent implementation.
Unknown command: interoperation",
309:
310: > One of the reasons that the TELNET protocol is so wide spread is
Unknown command: >
311: > that the client and server can negotiate the use of protocol options
Unknown command: >
312: > or extensions independent of the protocol "release". This allows
Unknown command: >
313: > the client and server to implement those options that make sense
Unknown command: >
314: > for the given platform/environment. In addition, the protocol
Unknown command: >
315: > development can move forward without forcing all implementations
Unknown command: >
316: > to upgrade (even for major release numbers). To my knowledge, the
Unknown command: >
317: > TELNET protocol was primarily advanced through the addition of
Unknown command: >
318: > new options.
Unknown command: >
319:
320: "Advanced through new options", yes, and no. I'd advise looking at actual
Unknown command: "Advanced
321: implementations. Basically, there is a mess of new and old options, with
Unknown command: implementations.
322: some old options having special hidden meanings that only work because all
Unknown command: some
323: of the implementations (and I suspect there are far few actual separate
Unknown command: of
324: implementations then it would appear) understand these same historical
Unknown command: implementations
325: tricks. I think everyone would agree with me that the mechanism did not
Unknown command: tricks.
326: evolve cleanly, and that the general concept has some basic flaws,
Unknown command: evolve
327: including the problem of negotiation when it is possible to get stuck in
Unknown command: including
328: extremely complicated negotiation loops, when even the basic idea of a
Unknown command: extremely
329: "negotiation phase" is absent. The existing code works, but that is about
Unknown command: "negotiation
330: it.
Unknown command: it.
331:
332: > I have not seen the list of protocol enhancements planned for the
Unknown command: >
333: > next version of VNC, but I understand it does include compression.
Unknown command: >
334: > Could it also include a way to negotiate options like compression?
Unknown command: >
335: > Then those options could be configured in the client and server
Unknown command: >
336: > based on issues like bandwidth and CPU horsepower.
Unknown command: >
337:
338: Obviously, some sort of negotiation is necessary. Personally, I'd advise
Unknown command: Obviously,
339: sticking with simple version numbers for the moment. Both the server and
Unknown command: sticking
340: client can thus agree on the maximum version of the protocol they will
Unknown command: client
341: communicate in. If any more advanced techniques are desired, they can be
Unknown command: communicate
342: implemented in a newer protocol revision, and thus be compatible with the
Unknown command: implemented
343: existing scheme.
Unknown command: existing
344:
345: > While this would delay the next upgrade of the protocol, it would
Unknown command: >
346: > also greatly enhance the configurability of the sessions. In
Unknown command: >
347: > addition, option negotiation lowers the barrier to entry for new
Unknown command: >
348: > server and client implementations (only the base is necessary to
Unknown command: >
349: > start using and testing new implementations with existing ones).
Unknown command: >
350:
351: I think you'll find that this is the exact opposite of the Vnc approach:
Unknown command: I
352: the server should be capable of dealing with the widest variety of client
Unknown command: the
353: requests, permitting the client to be the simpler implementation. I feel
Unknown command: requests,
354: this is an acceptable (and fairly unusual, as such things go) approach.
Unknown command: this
355:
356: > The encoding negotiation via "SetEncodings" already allows for some
Unknown command: >
357: > negotiable flexibility in the area of image encodings. However,
Unknown command: >
358: > there are other options or features that could also benefit from the
Unknown command: >
359: > ability to negotiate at startup:
Unknown command: >
360: >
Unknown command: >
361: > - Multiple framebuffers on a single session
Unknown command: >
362: > - Compression (yes, no, which)
Unknown command: >
363: > - Encryption (yes, no, which)
Unknown command: >
364:
365: Each of these things are only an issue if the server provides them, making
Unknown command: Each
366: them moot at the moment.
Unknown command: them
367:
368: > The TELNET protocol is documented in a slew of RFCs that were
Unknown command: >
369: > available from the Internic for a long time (www.internic.net).
Unknown command: >
370: > "rfc854.txt" is a good place to start reviewing TELNET. The
Unknown command: >
371: > following are also related: 930, 658, 652, 2066, 1572, 1571,
Unknown command: >
372: > 1416, 1408, 1394, 1372, 1205, 1184, 1091, 1096, 1080, 1079
Unknown command: >
373: > and 1073.
Unknown command: >
374:
375: You should also look at the (lack) of use of TELNET options in foreign
Unknown command: You
376: protocols (SMTP, for example) which were, in theory, designed to
Unknown command: protocols
377: interoperate with TELNET. RFC 1097 might also be useful as an example of
Unknown command: interoperate
378: one of the myriad of telnet features that is not commonly implemented, and
Unknown command: one
379: furthermore is unclearly defined as to affect. An example of the
Unknown command: furthermore
380: nontrivial characteristic of the TELNET negoiation mechanism is nicely
Unknown command: nontrivial
381: presented in RFC 1143. (Also absent from your list.)
Unknown command: presented
382:
383: > Finally and concretely, I would recommend that VNC be enhanced to
Unknown command: >
384: > support the "DO, DON'T, WILL, WON'T" style feature or option negotiation
Unknown command: >
385: > found in TELNET. This negotiation style would be used for all new
Unknown command: >
386: > features.
Unknown command: >
387: >
Unknown command: >
388: > Comments anyone?
Unknown command: >
389:
390: If you have to look anywhere, I'd suggest looking at PPP (RFC 1172). It at
Unknown command: If
391: least has a negotiation process that seems to work fairly well. Not
Unknown command: least
392: perfect, but certainly better then TELNET.
Unknown command: perfect,
393:
394: - --
Unknown command: -
395: Kenneth Albanowski (kjahds "at" kjahds.com, CIS: 70705,126)
Unknown command: Kenneth
396:
397:
398:
399: - ---------------------------------------------------------------------
Unknown command: -
400: The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
Unknown command: The
401: - ---------------------------------------------------------------------
Unknown command: -
402:
403: ------------------------------
Unknown command: ------------------------------
404:
405: End of vnc-list-digest V1 #245
Unknown command: End
406: ******************************
Unknown command: ******************************
407:
408: ===============================================================
Unknown action:
409: For more information see http://www.uk.research.att.com/vnc/intouch.html
Unknown action:
410: ===============================================================
Unknown action:
No valid command found - sending help.
Local error finding file.
The PostMaster has been informed.
Completed processing request at Sun, 28 Feb 1999 22:08:44 +0000
---------------------------------------------------------------------
The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------