Conference irocz::terminal_servers

RE: .0
    
>    1. Is there some kind of scripting facility available on the servers
>    which allows one to build in some logic on the server like load
>    balancing etc.
 
Not sure what you mean.  There is the Command Groups feature, which is a
form of command "macro", but it contains no facilities for branching or
conditional execution.  So the answer is probably no.  can you elaborate on
the requirements?
   
>    2. Can they have a transparent session as a tty over any protocol back
>    into a group of machines.
 
Again, your description is a bit vague.  Sessions can be "transparent" as to
binary data, to varying degrees.  As to any protocol, we support forward LAT 
and Telnet connections and reverse LAT, Telnet and Raw TCP connections.  The
group would be provided by a LAT service or DNS "CNAME" record that points
to a list of "A" records (one name maps to many addresses).
    
>    3. PPP session must be authenticated at the terminal server (I assume
>    that DRAS does this?)
 
There is authentication client software in DNAS for RADIUS, Kerberos V4,
SecurID, and local user names.  DRAS is a RADIUS authentication server.
Other authentication servers (Kerberos, SecurID, etc) are available from 
Digital and third parties.
   
>    4. DHCP support on the t/s through to the client.
 
Will be supported in V2.2.
   
>    5. Can the radius server back-end into any odbc database, or does it
>    only support it's own unique database?
 
Uh... I don't know.  I'll let someone else answer this one.
   
>    6. Can a port autosense a ppp or other type of session?
 
Yes.  We now support AUTOLINK to detect SLIP or PPP.  In V2.2 this will
be extended to detect SLIP, PPP or character cell terminal.  It will also
be extended to sense these protocols separately for the authentication phase
and for the session itself.

Regards,

Dave

    
    
    
    Hi,
    
    Thanks for your response so far,
    
    Here is the next round (reply comes from the customer Telkom, they have
    in excess of 100 decserver 700's and a few hundred decserver 200's, we
    have given them a proposal to upgrade all the 200's to 700's or 900's,
    could be as many as 5000 ports. Would Digital consider the
    option of developing some of their requirements? (at a reasonable fee -
    in order to secure the business). They are looking at competing products,
    some of which have scripting facilities that could satisfy their
    requirements. They do however want to stay with digital and retain
    their investment in the 700's),
    
    >>    1. Is there some kind of scripting facility available on the 
    >servers
    >>    which allows one to build in some logic on the server like load
    >>    balancing etc.
    
    >conditional execution.  So the answer is probably no.  can you 
    >elaborate on
    >the requirements?
    
    OK, heres the situation. We have a whole wack of Decservers in the
    field
    which we currently use to connect the POTS (telephone network) to our
    internal network. People connect to these servers and are autoforwarded
    via LAT to server machines. The first thing an incoming user sees,
    before he/she enters any data, is a prompt to select terminal type. The
    majority of these users use scripts (on their machines) to connect to
    us.
    
    *WITHOUT BREAKING* any of this existing stuff, and without splitting
    our
    modem/terminal server pool, we would like to support PPP/SLIP
    connections. This implies a solution like :
    The terminal server waits for a few seconds after it receives a
    connection to check the incoming stream for PPP/SLIP protocol. If it
    times out, it autoconnects to a LAT service.
    
    
    
    >>    4. DHCP support on the t/s through to the client.
    
    >Will be supported in V2.2.
    
    when will 2.2 be out ?
    
    >>    6. Can a port autosense a ppp or other type of session?
    
    >Yes.  We now support AUTOLINK to detect SLIP or PPP.  In V2.2 this 
    >will
    >be extended to detect SLIP, PPP or character cell terminal.  It will 
    >also
    >be extended to sense these protocols separately for the authentication 
    >phase
    >and for the session itself.
    
    Ahhh... Provided that once it senses a character cell terminal, it can
    be made to autoconnect to a LAT service, this is the ability we're
    looking for.
    
    
    
     Regards
    
    Peter

RE: .2
    
>    The first thing an incoming user sees,
>    before he/she enters any data, is a prompt to select terminal type. The
>    majority of these users use scripts (on their machines) to connect to
>    us.

How is this "prompt to select terminal type" issued?  By some script running
on the user's hpst (PC, etc) at the remote end?  Not from the DECserver,
right?  What actually gets sent to the DECserver to establish the connection?
   
>    *WITHOUT BREAKING* any of this existing stuff, and without splitting our
>    modem/terminal server pool, we would like to support PPP/SLIP
>    connections.

Right.  That's what everybody wants.  Implement new features without changing
old software.  Sometimes we can; sometimes we can't.

> This implies a solution like :
>    The terminal server waits for a few seconds after it receives a
>    connection to check the incoming stream for PPP/SLIP protocol. If it
>    times out, it autoconnects to a LAT service.
 
I think we have all but the "autoconnects to a LAT service" bit already
implemented in V2.2 in the form of extenstions to AUTOLINK.  What will 
happen is that the user gets a SLIP or PPP session or gets the Local> 
prompt on the DECserver.  While we have the capability of aotomatically
connecting to a LAT service, the feature that does this is DEFAULT PROTOCOL
and DEDICATED SERVICE.  To make AUTOLINK work you must set these to AUTOLINK.
To get the automatic connection you'd have to set them to LAT and the
LAT Service name, respectively.  So there is a basic conflict.

This is why I hadn't responded earlier.  I was trying to think of an easy
way to do this.  Perhaps using MENUs on the port.  This isn't something
that I've tested, and it may not meet the test of working with the existing
scripts (which we need to hear more about).
    
>    when will 2.2 be out ?
 
Ask the Product Manager, Jon Lewandowski ([email protected]).
   
>    Ahhh... Provided that once it senses a character cell terminal, it can
>    be made to autoconnect to a LAT service, this is the ability we're
>    looking for.
 
Ah, there's the rub.  Haven't figured out how to do that yet.  I know how
to do this if your customer would be willing to use RADIUS user authentication,
but I didn't get that impression from your description.

Regards,

Dave

    Hi Peter & Dave
    
    >>    The first thing an incoming user sees,
    >>    before he/she enters any data, is a prompt to select terminal 
    >>    type. The majority of these users use scripts (on their machines)to 
    >>  connect to us.
    
    >How is this "prompt to select terminal type" issued?  By some script 
    >running on the user's hpst (PC, etc.) at the remote end?  Not from the 
    >DECserver, riight?  What actually gets sent to the DECserver to establish
    >the connection?
    
    Spot on. The DecServer currently defaults to LAT and a DEDICATED service.
    This service is our application which is the source of the prompt.
    
    >> This implies a solution like :
    >>    The terminal server waits for a few seconds after it receives a
    >>    connection to check the incoming stream for PPP/SLIP protocol.If it
    >>    times out, it autoconnects to a LAT service.
    
    >I think we have all but the "autoconnects to a LAT service" bit 
    >already implemented in V2.2 in the form of extensions to AUTOLINK.What will 
    > happen is that the user gets a SLIP or PPP session or gets the Local> 
    > prompt on the DECserver.  While we have the capability of automatically
    >connecting to a LAT service, the feature that does this is DEFAULT 
    >PROTOCOL and DEDICATED SERVICE.  To make AUTOLINK work you must set these
    >to AUTOLINK.
    >To get the automatic connection you'd have to set them to LAT and the
    >LAT Service name, respectively.  So there is a basic conflict.
    
    >This is why I hadn't responded earlier.  I was trying to think of an easy
    >way to do this.  Perhaps using Menus on the port.  This isn't something
    >that I've tested, and it may not meet the test of working with the existing
    >scripts (which we need to hear more about).
    
    Hmmm... A menu could work if it did something like
    (1) Wait for port connection
    (2) Issue prompt (in this case three question marks)
    (3) Wait for input
    (4) If input is 1 - connect to SERVICE_1
          if input is 2 - connect to SERVICE_2
          if input is 0x7f (start of PPP header), switch to PPP mode
    Hardly ideal, since I then have to pull some fancy legwork in the
    bowels of my app to see what LAT service is incoming and fool the higher
    layers into seeing the choice. But it's certainly a good deal better than 
    some of the other solutions I'm contemplating. (you don't want to know - 
    makes this whole lot look positively elegant)
    
    >>    Ahhh... Provided that once it senses a character cell terminal,it can
    >>    be made to autoconnect to a LAT service, this is the ability we're
    >>    looking for.
    
    >Ah, there's the rub.  Haven't figured out how to do that yet.  I know 
    >how to do this if your customer would be willing to use RADIUS user 
    >authentication, but I didn't get that impression from your
    description.
    
    Hmmm, get the feeling that this "character cell terminal" feature isn't
    what I think it is... I thought it was the solution to the conflict between
    AUTOLINK and DEFAULT PROTOCOL=LAT
    
    I don't quite get the RADIUS comment. We're quite willing to run
    whatever is necessary to make the PPP work (that's a new service).
    
    Thanks,
    
    Noel