To: stik-beta-testers@list.zetnet.co.uk
From: dlanor@oden.se (Ronald Andersson)
Organization: Atari
Subject: Re: Question about CNgetinfo under STiNG
X-Mailer: NEWSie Version 0.94 (Atari)

Hi Dan,

please read the entire mail this time, before you 'cut' it.
There are some direct questions of mine which you have ignored
each time, thereby forcing me to repeat them (making mails larger).


>	I generally cut your messages as I hate 24k emails floating down
>the pike.  I'm not the only one,  that's why this list has shrunk to the
>size it is. lp and others left because they got sick of downloading huge
>messages arguing about how many angles can dance on the head of a pin.

An exchange of technical information can not be abbreviated below the
size needed to carry the necessary information.  I always try to include
all relevant data in an explanation of technical stuff.  Is that wrong ?

I fail to see the problem with mails of this size anyhow. The download
time for them is still completely negligible compared to beta releases,
and a quick read-through still only takes a minute or two max.

Then if the reader is not interested in the subject he can just delete
the mail (at a very small time cost that is independent of its size).
But if he _is_ interested he should settle down for a _proper_ reading
without which a reply on technical issues is useless anyway.

I don't see any problem with this.  Why do you ?

In any case I have no choice this time.  You have made a number of
statements that demand replies.  I do hope you read them this time.


>	Now you get in a huff about multiple IP addresses.  But under any
>normal applications, clients only see one IP address on a machine.

Here you are using the word 'normal' in a way adapted only to single-port
stacks. In any multiple-port LAN context with local servers in use, that
statement is untrue.  There is no way to tell the difference whether the
client is currently in use with a LAN based server or one on a remote
network.  That fact is only known on the machine that does the final
routing of LAN traffic to/from the external network (ie: Internet).

That is why I say that the stack needs to know the remote IP of the
new connection if it is to correctly deduce its route, and so know
the local IP that will be used when connection is established.

I asked you before, and now I have to ask you again:  How is it possible
to deduce that route when the only information passed to TCP_open is the
number of the local port ?

You have said several times that this must be done, and that it is done
by all other stacks, so please tell me _how_ it can be done.


>Whether it's implicit or broght back from the resolution of an ip address.
>It's possible to look at the other IP address, but in general for a client
>it's not necessary or worthwhile to do so.

I do agree with the last.  Even so, it is possible to look at the IP address
with STinG as well.  When a connection has been established it can even be
done by exactly the same code used for STiK.  It is only when a connection
has not yet been established that STinG needs some more info to know the
route.


>	I originally typed in a very long message quoting large sections
>from Wright/Stevens and the actual BSD code.  Then I stoped myself.  Why
>it's not of interest to most of the people on this list and frankly I
>don't care.

I agree that it would have very little relevance.


>If you don't want to fix something in STiNG, then don't fix it.

I am not in charge of STinG development, so that is not up to me...
I do have some influence, as can any STinG-related author, but any
changes must be agreed upon through discussion. That's how it works.

As for what I want, that does include several changes both to the
STinG kernel and the TCP STX, most of which were under serious and
continuous discussion by Peter and me at the time he lost his ISP
account.  As soon as he gets another I intend to resume discussion
on those subjects.

Amongst the changes I want are some that concern STiK compatibility,
and even the updating of data in the CIB structures.  But I see no
way to get the local IP field updated before a connection has been
established if it has been opened with the oldfashioned TCP_open
call that can't supply remote IP address to be used.

That is why Peter and I have tried to interest you in some TCP_open
enhancements that would fix this problem once and for all.

As I recall you stopped replying in that discussion, leaving us
with no choice but to implement what we felt was needed.  The
resulting TCP_open enhancement is fully documented in the latest
STinG.HYP made available to everyone here.  I suggest you look at
it, since you might even find it useful to implement a similar
scheme in STiK.

Perhaps you already have some such enmhancement in STiK, but then
I can't know that, since you never share such info here, except
to mention that you have some improvement or other.  You have
never given any specs of them, or said where such can be found.

That makes it a bit hard for me to work for compatibility.
(Which is something I have always prioritized.)


>Just don't complain when something doesn't run on it.  Many
>programmers that we have on this API don't program for either STiK or
>STiNG they program for GlueSTiK.  They don't care what super slick options
>you put into STiNG.

I know that many program without regard for STinG, and IMHO it is a pretty
good 'score' for STinG compatibility with STiK, that most such clients work
very well indeed, without any adaptions.


>	In the past several of us suggested you consult linux et al, on
>the functioning of your masquerade.stx.  Your reply was they did it wrong.

No, that is not my latest word on that subject.  I still think that some
port limitations they chose are unsuitable, but in light of newer sources
I was given by Peter I do see how it works. (The older sources were wrong.)
Peter and I discussed this some time ago in this list, so I am surprised
that you still refer to the older matters as being relevant.

The planned Masquerade improvements include high-level protocol masking
possibly using a modular design to allow simple extendability.  That too
has been mentioned here before, in some detail.  This would allow fully
functional IRC DCC and FTP PORT commands between LAN-based clients and
servers on the Internet (or vice versa).

The problem of getting a valid local IP number without telling the stack
which remote IP it is intended for remains however.  That is the only
thing in such clients that would require a workaround for STinG.

We are talking of just a few lines of code in an entire client...
Is that really too much ?  I don't think so myself.

Especially not as my recommended workaround also works identically for STiK,
so that the client program never even has to test for STinG...
(You still have not mentioned one argument against that workaround.)

At present the workaround does not solve any masquerading problems, but it
does give proper operation for all other traffic, and the masquerade module
will be updated in such a way that the workaround then works even for all
masqueraded DCC stuff etc.

Now please tell me what you find so wrong about this.
(All of this was in last mail too, but you ignored it.)


>I still have the message in my mailbox here if you want me to refresh your
>memory.

Do as you please, but remember to read _all_ I have written on the subject,
and please don't quote older messages out of context.  That would only be
misleading.  (And I don't _need_ to be reminded anyway.)

Since you refer to my stand on masquerading as 'the message' in singular
form, I can only assume that you have missed a lot of my mails on this.


>All I can suggest is that you do that.  'Masquerading' if you
>want to call it that, existed on other stacks before you wrote your own
>layer,and they don't require special modifications to the clients.

I've already done that, have you ? That's where I got the 'Masquerading'
term from, you see.  They use it quite consistently in those sources.
And yes, they do not need client modifications to work with the clients,
but that is because the clients work differently from the start there.

They do not have the limited TCP_open call of STiK to work with, but can
open a listening socket such that the remote IP it will accept calls from
is specified, which means that the return route can be deduced.  For STiK
the lack of that ability means nothing, as only one local IP exists, but
it means more to STinG which allows many local IP numbers.  That is also
why STinG has enhanced TCP_open modes (which you refuse even to discuss).

NB:  Correctly opened listening connections for FTP PORT commands or
     IRC DCC commands should be listening ONLY for packets from one
     specific remote IP. That's not possible with old STiK TCP_open.


>	I really hate arguing with you, in general it's been pointless.

Perhaps, but I think that is mostly because you dislike reading any large
mails (as you said at the start of this).  Another factor making it hard
is that you almost never answer any direct questions I make.  This is
possibly part of the same problem, since it often seems as if you cut
my mail before having read it completely.


>I pointed out an initial problem with the CNgetinfo call, to which I was
>told it was done for internal functions  STiNG.  Well if it was internal
>then why didn't you just do a wrapper call?  It would't have added much
>code and would have remained compatible with the STiK API.

The internal call I showed you, which is also available for external
programs, needs the remote IP address to calculate parameters for the
future connection, such as the local IP appropriate to use for reaching
that remote IP.  The old TCP_open call does NOT supply any remote IP
when used for listening connections.  That makes a wrapper useless.


>I think it was modified to become incompatible with the STiK API.
>But it backfired.

That is a silly statement.  Who could possibly gain anything by that ?
I can't even see what the aim of it would have been, and consequently
I can't see what you mean about that purpose having backfired either.

The only reason why this incompatibility exists is because we CAN'T
resolve a future local IP for a connection given only the local port
number, because that provides NO routing information.  For that the
known future remote IP must be used, which is not passed by STiK's
TCP_open call for listening connections.


>This is the reason that AtarIRC has problems with STiNG.

AtarIRC has problems only with some aspects of its operation, mainly DCC.
The reasons for that are clearly described above and in older mail.


>Peter didn't bother telling anyone.

That is not so.  He has sent it out to everyone in this list.
He can't very well visit each of us personally to make sure we
also read what he sent us.  That would be totally insane.


>He put it into a HYP that many of us have never downloaded let alone read.

Why ?  To anyone who is interested it is an obvious and easy thing to do.
Once you have the HYP installed you can use ST-Guide at any time to check
any STinG questions you have, even in the midst of program editing, which
I find the greatest benefit of an ACC-based document system like ST-Guide.

Anyway, I find it pretty farfetched to blame him for the fact that you
and some others do not want to read his docs.  That was your decision.
If you don't read docs, you will miss information.  It's that simple.


>When I pointed it out to him, he was pretty hot.  And you know what?
>He doesn't plan on changing it.

What are you talking about ?  Are you saying that he should NOT produce
easily accessed docs in a fast and efficient hypertext format and make
this available to everyone for simple help in STinG-related programming ?
I certainly hope I misunderstood you on this !


>If you read his
>doc file, you will find that it warns that AtarIRC is not STiNG
>compatible.  This is not the only application that this problem comes in.

AtarIRC is compatible to STinG in normal channel usage, but it does have
some problems, as discussed above and previously, with the DCC stuff.
The reasons are as I have described and could be solved easily by any
of the workarounds mentioned. The only reason for not using the simplest
of these, that works identically with STiK too, is that you (or lonny)
actually want the operation to fail under STinG.


>	I know there are work arounds, but frankly the market is so small
>anymore I really don't care.  I know that sounds really sad, but it's
>true.  

You don't care ?  Just because the PC/Microsoft market is spreading ?
I know the Atari/TOS_clone market is small, but then it always was.
My feelings about it do not change just because others abandon it.

In any case, the workaround I've asked you to do is so extremely simple
that I am surprised you make such a fuzz about it.  After all, you only
have to edit the argument of one CNgetinfo call which is already used.
what is so bad about that...?

No STinG recognition is required for it as it works identically with
STiK too.  If you really want a solution I'd expect you to welcome
this one, but since you reject it I still want to know why.


>	All I can say is if you don't want to look at any of the other
>implementations of masquerading, then at least look at RFC 1631.  It's not
>the best RFC in the world, but it at least describes some of the steps
>that are necessary in the route you have taken.

As mentioned above, I have studied other implementations, but I had not
noticed this RFC 1631 before.  "The IP Network Address Translator" is
apparently the title (according to my index), so it should be interesting
reading even if not completely applicable.  I'll download it ASAP.
Thank you for the ref.


>	And if you don't want to fix the CIB, then I guess thats ok to.

It's not just a question of 'wanting'.  There are technical reasons
why a fix as described by you can't work. Essentially it would mean
forcing STinG to use a single local IP number for all traffic, no
matter to/from which ports it is routed.  That is not a good idea,
since the IP numbers are what routing is based on.


>I'll just start putting qualifiers on projects.  It's not a threat, it's
>just a basic statement.  Right now I have to scan for Peter's name and
>implement code specifically for getting the info in STinG.  The recent
>scare of peter, stressed the fact, that it's not a good plan to do that.

Wrong.  Though I have released (in this beta list only) a patched TCP
module, that still contains Peter's name as originally written by him.
The only difference is that I have added " & RA" at the end of that
string, and have incremented the version number.  But I don't think
you check the latter anyway, from your description.

In any case, I would never consider removing Peter's name from any of
his modules, no matter how patched.  That would be theft !


>	Sorry if I caused any distress or unhappiness.  I'll go back to
>reading this list on rare occasions and not participating;)

Do as you please, but I think that would be an overreaction.  I also
would appreciate it if you would answer at least some of the direct
questions I have asked you in these mails.  So far you have ignored
them all.

