To: perot@pallas.amp.uni-hannover.de
Subject: Re: [4] STiK 2 testing etc.                                                     


On Wed, 19 Feb 1997 10:37:09 Peter Rottengatter <perot wrote: 
>
>On Tue, 18 Feb 1997, Ronald Andersson wrote:
>> 
>> I assumed as much, and I do prefer it to the 'normal' CPX method of saving it
>> in the CPX itself.  But I would prefer a single file even more.
>
>The first I'd preferred too. Problem was that the number of ports to be 
>treated (i.e. variables to be saved) is variable. I thus cannot reserve a 
>fixed amount of space at the beginning of the DATA part of the CPX.

Slight misunderstanding here...: I would NOT like it saved in the CPX.
But doing that would be simple, just by defining more space than normally
needed, and saving it all regardless if used or not.  But having it in
the CPX makes use of the CPX mandatory, which is unacceptable.


----- snip ----- re: the use of 'gateway' in ROUTE.TAB
>
>It is not necessarily unique for the port. You might have two other 
>networks to be reached via the considered LAN, but both connected to 
>different gateways in that LAN :
>
>         EtherNet
>---+-------------------+---------------------+---------------------+-----
>   |                   |                     |                     |
>Our ST             Gateway #1            Gateway #2           More machines
>                       |                     |
>               Remote Network #1     Remote Network #2
>
>The routing table for the ST will have three entries for the EtherNet 
>port : The first describing the EtherNet itself (Gateway entry is 0.0.0.0),
>the second describes a route to the remote network #1, the third the 
>route to remote network #2. Thus three entries for one port, with three 
>different gateway numbers. The port netmask is the one that also goes 
>into the first entry, because it describes only the local EtherNet.
>For some special configurations not even this is true, you might want to 
>address only a part of all the Ethernet hosts via the route, then the 
>EtherNet route netmask is different from the port netmask.

Excellent.  This was the conclusion I too reached in some sections below.
In your earlier explanation you simplified the role of the gateway, making
it appear port specific rather than subnet specific like it really is.
Thus it is the latter form of my suggestions below that is valid, which
does preserve the structure you wanted, but includes the port stuff too.
I really do think that is appropriate, since it too affects the routing.


>I appears to me right now that the netmask entry in the STIKPORT.CPX 
>possibly can be trashed altogether, if we force people to set up a route 
>for each host. Default routing doesn't work anymore in that case, but a 
>proper net setup won't require it anyway. I'll check this.

Surely STiK.PRG can init sensible defaults anyway during module loading.
You obviously have some data structure for each port holding its parameters,
and unless specified otherwise the port netmask in it could be initialized
to something useful (say 255.255.255.0).  But there should still be *some*
way to specify it in detail, at least by editing ROUTE.TAB or similar file.


----- snip ----- re: bad example based on erroneoud gateway assumptions

Ok, that was garbage... :-)


----- snip ----- re: valid example  based on correct gateway assumptions

>> Subnet section:
>> 
>> subnet_number	subnet_mask	port_name	subnet_gateway
>> 
>> Port section:
>> 
>> port_name	port_IP		port_mask	parameters
>> 
>> This is identical to your current model except for including the port data
>> as well,  which makes it possible to understand the routing of this machine
>> entirely from this single file.  That is currently not the case.
>
>Without default routing, like I said above, all routing data is in 
>ROUTE.TAB anyway, without further changes. I do not like much the idea of 
>including all the CPX's data into the ROUTE.TAB, as effort must be spend 
>to separate data which must be ignored by the core, whereas the CPX must 
>store all data it is not interested in, in order to save a proper file 
>afterwards.

That is a wasteful way of doing it.  It can be done by scanning the file
in R/W mode, so as to eliminate all old port definitions from it and then
appending the new definitions to the end of the file, or after a keyword
line (preserved).  The latter allows user remarks both before and after
the port definition lines.  (though not on those lines of course)
The algorithm wouldn't have to deal with more than one line at a time,
and no intermediate file would be needed (I was wrong about that before).

Would you like me to code it...?


>Maybe I missed something, but I do not see the difficulty you're stating 
>here. A nice setup would have all routing data in ROUTE.TAB anyway.

Not unless the port netmask is eliminated, which I do NOT want.
The port data should be collected in a single file, and since it includes
the port netmask that file should be ROUTE.TAB.


>> Actually I prefer this model.  A gateway should be specific to the ultimate
>> destination rather than to the port, but you described it as port specific.
>
>Did I ? Then I can understand your confusion, and then it'd not be  
>justified to have it in ROUTE.TAB. But it is not a port's feature, it is 
>merely associated with the port in that is is reached via the port.

Right I've got that now, and all stuff in this mail is based on it.


>> Also, 'parameters' represents the other stuff currently put in STIK.INF
>> 
>> Note that I do not think COPS or XCONTROL should be necessary to use STiK.
>> Yet my suggestion is no hindrance for using the CPX to alter the data either.
>> As I said below:
>
>Note that there is still ConfSTiK to be finished, which will allow doing 
>all configuration from a single file.

Right, and I believe that it should use ROUTE.TAB in the same way that
I want the CPX to do it.  It really is quite simple.


----- snip ----- re: the use of ROUTE.TAB by CPX
>> 
>> Actually I think the current ROUTE.TAB structure is misleading, in that the
>> gateway is defined without any mention of the port net_mask which will decide
>> when that gateway is used.
>
>Aha, here is where your confusion arises from. It does not work like 
>"port netmask does not fit, thus use the gateway". The proper response to 
>a situation where no netmask does fit is sending back an ICMP `network 
>unreachable' code. This is what the current ST2K core already does.
>The gateway from a route is used _only_ if the netmask and template 
>(net address) specified in that route _do_ fit.
>
So when *is* the port netmask used then...?

Take a simple Midi ring for example, seen from one of it's machines:

I must have a subnet line in ROUTE.TAB for the other machines, and that line
specifies subnet_number subnet_mask and no gateway (zeroes) using Midi port.
For each subnet reachable through one of the others I must have another subnet
line for the Midi port, using the relevant other machine's Midi IP as gateway.

So where does the port netmask come in...?
If used at all it does seem utterly redundant.
Was that what you meant about removing it above ?
If so, I guess I agree after all.


>> I don't really care whether the structure of config files resembles any network
>> programming model or not.  They should still allow editing of information that
>> is related in terms of their effect, in a simple convenient manner.
>
>I guess I provided some information in a misleading way, that made you 
>think this were not the case ?

Right, these things happen.  I've got it straight now though.


>> If you don't want to mix the info of STIK.INF and ROUTE.TAB, that is ok too,
>> though I would definitely prefer having a single file for this purpose.
>> But if the STIK.INF shall remain it must be user editable, or it will never
>> be accepted.  I'm not talking about myself now, but about the list members.
>
>Remember ConfSTiK, which is text-based. I had in mind a configuration 
>file that comprises ALL configuration info, which will be split into the 
>ROUTE.TAB, ... at run time by ConfSTiK. To that end I intented ConfSTiK 
>to be run from the AUTO folder after STiK. It's just that I recently had 
>not time to work on it, I thus mentioned it rarely.

Ok, that unified config file idea will please some of course, though others
will complain that the splitting operation is wasteful.  Martin is bound
to 'prove' that with tests on floppy under TOS 1.0 (unless he can find 0.98).
He still claims that TOS 1.0 used without bugfix patches is most 'normal'.
(Pathetic really.)


Anyway, I think the final release will have to have yet another config method.
People in the list have been harping on the subject of complexity, and the need
of users who never heard of 'routing' to simply use STiK traditionally.

I think this is easily catered for by having some standard setups prepared,
and a super-simple program that just lets the user choose the setup type and
enter his ISP data.  This super-simple program is the one that should be
directly visible in the 'root' of an archive with the 'real' stuff, that we
and other networking users want, being 'hidden' in a subfolder (\PRO_USER\).

I agree that it is really far too early for these things to matter, but many
in the list bring up such things as if they were a real hindrance to go on
with the STiK project.  I find that ridiculous at this stage, but think we
have to answer it with plans like the above anyway.


>> Sorry to disagree so much this time, but I really got tired of this split
>> configuration stuff in my tests earlier. I don't mind the CPX being available,
>> but I didn't like being forced to use it as the only way of setting things up.
>
>I never intented to, I just wanted a GEM based way to do it, too. Many 
>other people asked for it as well. That does not mean there should be no 
>text-based approach.

Good.
In the end there is no reason why we can't cater to all tastes in this.
As long as the actual files are ascii based, the means of changing them
are legion, and each can choose for himself what he prefers.


Ps: I don't want to nit-pick on spelling normally, but I've noticed one
    error you make so consistently that it must be due to a misunderstanding.

    "Intent" = a noun, with adverbial form = "Intend"

    Mixing these up normally doesn't affect the meaning much, since it is
    usually evident from the context which is intended.
DS.

PPS:  I hope you didn't mind...
DS.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
