Number: 2105

Date:  7-Sep-84 04':23':59

Submitter: acuff

Source: acuff

Subject: Need to create standard method for finding what protocol to use

Assigned To: 

Attn: vanMelle, JonL

Status: Open

In/By: 

Problem Type: Design - UI

Impact: Moderate

Difficulty: Very Hard

Frequency: 

Priority: Unlikely

System: Communications

Subsystem: Other

Machine: 

Disk: 

Lisp Version:  4-Sep-84 19':45':00

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Sannella.PA" "11-Sep-84 12':51':11" Subject': Attn': Status':(New->Open) Impact':(Serious->Moderate) Priority':(->Unlikely)]'
["vanMelle" "14-Sep-84 15':18':33" Subsystem':(->Other)]

Description: A mechanism needs to be put in place to allow a program to determine what suite of protocols it must use to communicate with a particular host.  I propose the following':'
'
   Introduce a function FIND.PROTOCOL.SUITE which will take three arguments, the name of the host being sought, a list of protocols which should *not* be used, and a list of "hint" protocols which, for some reason, the caller thinks are likely to work.  There would be a list, HOST.FILTERS, of filter fns to be called by FIND.PROTOCOL.SUITE.  Each filter fn would return the name of a protocol if it determined that the host could be reached via that suite, while a NIL return would only indicate undecidedness.  This would allow a large degree of flexibility in ordering this "search list" so that the most likely filters occurred early in the list.  For instance, a fast version of a fn looking for PUP support would only look around at what the workstation already knew, it wouldn''t access the net, but it''s slow conterpart (further down the list) might prod a name-server.  This also allows "special cases" to be handled nicely by the user.  The "don''t use" list can be passed to the filters (they know best how to use it), and the result of a filter can be double checked to make sure it isn''t on the black list.  Handling the hints is a little harder.  A list of potential returns from each filter would need to be associated with it so that it could be determined whether or not it should be called.'
'
   Once the suite it determined, it is still necessary to determine which actual protocols (eg. telnet) are supported.  I propose that GETHOSTINFO be used to provide this information.  A set of names for the standard services would need to be produced to be returned.  For instance, CHAT could use (GETHOSTINFO NAME ''TELNET-SUPPORTED? PROTOCOL) to determine something about how well TELNET is supported on host NAME under protocol suite PROTOCOL.  The return might be NIL for no support, UNKNOWN, or T.

Workaround: 

Test Case: 

Edit-By: vanMelle

Edit-Date: 14-Sep-84 15':18':34