送信者: Ari Mujunen <amn@kurp.hut.fi>
宛先: Tetsuro Kondo <kondo@crl.go.jp>
Cc: Alan R. Whitney <awhitney@haystack.mit.edu>; Wayne Cannon <wayne@sgl.crestech.ca>; Brent Carlson <bcarlson@sol.drao.nrc.ca>; Dick Ferris <dferris@atnf.csiro.au>; Dave Graham <p062gra@mpifr-bonn.mpg.de>; Nori Kawaguchi <kawagu@hotaka.mtk.nao.ac.jp>; Sergei Pogrebenko <svp@jive.nl>; Misha Popov <mpopov@asc.rssi.ru>; Jon Romney <jromney@nrao.edu>; Ralph Spencer <res@jb.man.ac.uk>; Ed Himwich <weh@gemini.gsfc.nasa.gov>; JUNICHI NAKAJIMA <nakaji@crl.go.jp>
件名 : Re: VSI-S draft 2
日時 : 2001年4月3日 22:48

Dear VSI-S group,

On Tue, 3 Apr 2001, Tetsuro Kondo wrote:

> >  5.1 Packet Structure
> >  Each communication to/from the DTS is an elementary packet of the form:
> >  <SOH><command/response><S><C><EOT>
> 
> Japanese group are perplexed with the modified VSI-S Version 2.0.
> Especially at the point of the packet structure cited above.
> 
> The VSI-S control sequence is established on reliable
> ethernet or RS-232, and already they has own error correction mechanism.

I agree on the comments made by both Ed Himwich and the Japanese group in
that a simple "ASCII command line" to a given VSI unit should result in a
simple "ASCII response line" being returned.

I'd expect that the typical VSI unit will prefer to use Ethernet and
TCP/IP in the very simple TCP fashion, "telnet style".  TCP guarantees
error-free delivery of command/response lines without any sequence
confusions.  I.e. the very basic TCP "socket server" can listen and accept
incoming connections on an agreed TCP port number, and whenever a line of
ASCII appears, it can reply with another ASCII line using a pretty short
timeout.

If we wish to define any additional safeguards for a RS232 or RS422
implementation I think this is best left to be handled on top of the basic
underlying "line in, line out" mechanism.  As Ed noted, on RS232 it may be
useful to have an unambiguous "start of line" character.  It may also be
applicable to append a checksum and/or sequence number, but this should be
done only as to "emulate TCP" on top of RS232---perhaps we can actually
leave this undefined since I'd be surprised to see any VSI devices
appearing which do not implement Ethernet and TCP/IP...

I also agree fully with Ed with the principle of VSI devices "talking"
only when they are sent a query command, and that every command must
complete quickly, much faster than the defined timeout period is.
Lengthy operations must only be initiated by a given command, not
processed to completion before returnin response ASCII line.

The quick response provides feedback about that the command was accepted,
but another "query progress" command must be used to poll the real
completion status. 

Simple ASCII "line in, line out" communications style has the additional
benefit that VSI devices can be talked to using 'telnet', simply by

  telnet vsi-dev.somewhere.net 5678

where 5678 represents the to-be-decided standard VSI port number.

A basic example of required "VSI server" functionality is shown in GNU C
Library documentation, available on most Unix/Linux systems by invoking
'emacs' and browsing the Info file of 'Libc' as follows: 

  C-h i
  C-s libc RET
  RET
  C-s sockets RET
  RET
  C-s connections RET
  RET
  C-s server example RET
  RET

where you can see the 100-line sample program accepting incoming "telnet
computername nnnn"-style connections and processing incoming messages.

Best regards,
Ari Mujunen
Metsahovi Radio Observatory


 