[nos-bbs] A question...

[Barry Siegfried]

["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

> As many of you know now, I am engaged in documenting jnos in a new form
> - the wiki.
> As I structure this I note some issues like the following.
> This is probably flame fuel - but here goes.
>
> For the BBS, the syntax is:
>   CONNECT INTERFACE STATION DIGI
>   CONNECT STATION
>
> For the sysop, the syntax is:
>   CONNECT INTERFACE STATION DIGI
>   NETROM CONNECT STATION
>
> OK - I left out a couple details, but by look / the interfaces are not
> symmetrical.
>
> Has anyone considered changing the sysop interface to support "connect
> station" for net/rom?

Yes, but only if it is "not possible" to connect via AX.25.  I have a
compile-time option for that in my own NOS (where there are no directly
accessible "user" AX.25 interfaces in my program).  I can save a good
amount of space by decompiling the ability for anyone to make a direct
AX.25 connection using a machine interface.  Under those conditions, my
"connect" command verb gets pointed to the Net/Rom command module.

> Does anyone else see value in using the same command structure on the
> two interfaces?

Of course.  Obviously WG7J programmed it this way in the mailbox so
it's doable, but the code mechanics of parsing a mailbox user command
are different from those in the top-level system command processor.
It all depends how interested you are in making it happen and whether
or not you want to spend the time trying to develop the code for it.

> This may be "much ado about nothing", yet I wonder if this contributes
> to a smaller usership for jnos...

I seriously doubt it!

> Jay, I think we disagree on a small detail?
> 
> > Greetings Skip,
> > 
> > >>SNIP<< This is like comparing Apples and Oranges.
> 
> Nope - they are both requests to do the same thing "PLEASE CONNECT
> ME TO ANOTHER HOST"

Be careful now.  You are speaking strictly from an end-user-I-don't-
care-how-it-works point of view.  Jay is speaking from the point of
view of the code parser and layering seperation.

> They both employ only AX.25 technology.

One employs "simple" AX.25 technology to carry application data.  The
other employs AX.25 technology as a real link layer 2 to carry frames
that have network level 3 "smarts" in it, which in turn has a transport
layer 4 and then the application underneath that.

> Without the "net" the user paws thru the JHEARD list and then
> provides the details.

Regardless of what you *see* in JHEARD, by definition level 2 (AX.25)
has no network routing "smarts" in it (FlexNet notwithstanding).  It
is not technically the function of the Jheard list to tell the user
where his packets are supposed to go by simply specifying a hostid.

> With the "net" the user paws thru the NODES table and then provides
> no detail.

Because the function of the level 3 Net/Rom nodes list is to provide
Net/Rom *routing* data using a physical interface in the machine.
This functionality is then passed to the user by having the machine
select the correct interface and Net/Rom neighbor to use in order to
set up the connection.

> In both cases the result is the same with a new BBS (or "net" tool)
> at the remote site.
> 
> It is my opinion (only opinion) that the BBS pair of commands is fully
> consistent.

As you can see above, it isn't consistent from the layering model point
of view.  And unfortunately for the end user, NOS was originally coded
by an individual who was using the layering model as his guide.

> At worst the above is a "breed of apple" condition.
> If you want an orange, compare "connect" with "telnet"?
> With telnet you again get the same response as connect from the
> remote host, but the protocol of getting there is different.

Yes, but the layering *functionality* of IP (level 3) and TCP (level 4)
is absolutely identical to Net/Rom's level 3 and Net/Rom's level 4.  Yes,
Net/Rom has two distinct layers... one provides routing data (just like
IP) and the other provides end-to-end reliability (just like TCP).

> >>SNIP<<

> I expect the logic in processing the "connect" command might be touchy
> to resolve the ambiguity between multiple ports plus multiple
> occurrences of the remote host ID.

Good thinking and I'm glad you caught that!  That is yet another problem
of just HOW would you write code to use the Jheard list for identifying
a hostid and its associated interface(s)?  In order to do that (like
Net/Rom's layer 3 does where there may be multiple paths to the final
destination) you would have to add some kind of metric for the hostids
which are "heard" on the interfaces.  Presuming you could decide exactly
*how* you would assign these metrics, if you think about it a bit you
will realize that this would then introduce a rather complex set of
algorithms which would then need to be coded and utilized for selecting
the "right" interface on the Jheard list.

> >>SNIP<<
> 
> The answer is not here yet - one screen requires "connect host" the
> other "netrom connect host" for identical conditions.
> Is that apples and oranges?

Yes, I'm afraid it is.  Can this be programmed differently?  Of course.

Does anyone here think it is important enough to invent a system for
doing it and then coding it?

I doubt it.

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at k2mf.ampr.org         |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+