Received: by maskin (mbox dlanor)
 (with Cubic Circle's cucipop (v1.31 1998/05/13) Sun Apr  4 23:59:38 1999)
X-From_: owner-stik-beta-testers@list.zetnet.co.uk Sun Apr  4 19:43:47 1999
Received: (from uucp@localhost)
	by maskin.ettnet.se (8.9.1a/8.8.8) id TAA27528
	for <dlanor@oden.se>; Sun, 4 Apr 1999 19:43:47 +0200 (MET DST)
Received: from UNKNOWN(194.247.47.34), claiming to be "spodden.zetnet.co.uk"
 via SMTP by maskin, id smtpdAAAa006i3; Sun Apr  4 19:43:30 1999
Received: from majordom by spodden.zetnet.co.uk with local (Exim 2.05 #1 (Debian))
	id 10TqvK-0001rg-00; Sun, 4 Apr 1999 18:43:06 +0100
Received: from dilbert.netset.com [206.183.227.13] (baldrick)
	by spodden.zetnet.co.uk with esmtp (Exim 2.05 #1 (Debian))
	id 10TqvH-0001rS-00; Sun, 4 Apr 1999 18:43:04 +0100
Received: from localhost (baldrick@localhost) by dilbert.netset.com (8.8.8/+dilbert+) with ESMTP id NAA15853 for <stik-beta-testers@list.zetnet.co.uk>; Sun, 4 Apr 1999 13:43:00 -0400
Date: Sun, 4 Apr 1999 13:43:00 -0400 (EDT)
From: Dan Ackerman <baldrick@netset.com>
To: stik-beta-testers@list.zetnet.co.uk
Subject: Re: Question about CNgetinfo under STiNG
In-Reply-To: <199904041626.SAA25289@maskin.ettnet.se>
Message-ID: <Pine.LNX.4.10.9904041249570.15573-100000@dilbert.netset.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stik-beta-testers@list.zetnet.co.uk
X-Loop: stik-beta-testers@list.zetnet.co.uk
Precedence: bulk
Reply-To: stik-beta-testers@list.zetnet.co.uk



On Sun, 4 Apr 1999, Ronald Andersson wrote:

> 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).
> 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.

	But what you say is not true.  I'll give you one example here of
something I was just working on in the last couple of days.  Mac OSX
server has more than one IP address.  One is the actual IP address of the
machine and one is the ip address or the BlueBox.  BlueBox apps always get
the BlueBox IP address and Yellow Box the Yellow box IP address.  

	Now how does this translate into the above problem.  Easy it's a
question of domains.  If you are running a system with 'masqueraded' ip
address, clients grab the masqueraded IP addres only.  Now this is the
route that goes down RFC 1631 (which we can accept or throw out since it's
one of the modern, written by a company RFC's for the specific purpose of
providing a product to support it).  Now this causes the excess
manipulations of packets on the actual router since it must now scan and
massage data, which in the end will fail for many applications since it
just can not know.  

	Now there is a second route that is much easier to impelement and
avoids the problems we have before encountered.  When does an application
need to know what it's IP address is?  When it is going to be passing the
IP addres across the network.  Such as dcc, ftp, icq or a host of other
applications.  Now when we pass the IP address, of course we need the IP
address to be valid for the client no matter what happens (local traffic
or external traffic).  In this case there is only the one IP address that
fits the bill, that's the Real IP address of the stub router for the local
network.   

	This increases trafic on the router on the system.  That's a
problem if you have slow machines, but this is why you will often see
linux users setting up a slower older cheaper machine in the corner to
operate as the router.  But it has the benefit that no data in packets
needs to be manipulated internally.  The only manipulation needed is when
the router is operating and linking the connections.  Providing a proxy or
tunneling service to the rest of the computers on the network.

	I'm not certain what the full function of your masq.stx is, but
ideally this would provide/replace the current open functions in the API.
Providing network requests for these functions to the actual host/router
machine.

	The only downside to this method is the increased trafic on the
router.  If on a 3 machine network, machine wants to connect to something
on machine 2, it still handles it's traffic trough machine 1 which is the
router.


	What's the benefit of this sytem... All clients should work by
default.  DCC, ftp etc.  They are always passing the real ip address for
the network across the connections.  They don't need to worry about this
not being their IP address, since they are referencing the packets by a
connection handle.  A connection handle that is linked to the real
connection handle on the stub router of the system.


	This does make a lot of traffic on the router if you have a lot of
machines on a local network.  In those cases it's only intelligent to
designate the machine used least often as the router.  If it's a network
of 2 or 3 machines, the increased trafic on the router shouldn't be that
noticeable unless it's an 8mhz 68000 machine, in which case it's probably
not acceptable for much extra use.

> 
> 
> >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.
> 

	See above.

> 
> >	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.
> 

	Not entirely.  If someone says an apple is not an apple, it's
sometimes usefull to cite the dictionary definition of an apple.

> >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.
>

	Yes it is a good score for STiNG.  It was a better score before
peter put in the CAB in the CIB.

> >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.
>

	The client does not necessarily know which machine is going to
connect to it.  With dcc yes one generally does know what ip address is
goig to connect to it. With ftp it is possible to have a seperate machine
vending files than the one handling the control connection.

 
> 
> >	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 read through most of your messages note, I did say most.  I cut
and clip when you seem to have misunderstood me and gone off on some long
post along a seperate line.  


> 
> >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.
> 

	You don't see the insertion of the CAB structure as an
incompatibily?



> 
> >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.
> 

	Yes it's described in the previous line of mine.  AtarIRC looks
for a CIB, instead it gets a STiNG CIB, which is not compatible.  So it
fails.

> 
> >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.
> 

	Hmm, must be several of us that missed it then.  Was kind of a hot
topic on #atari one day.  As several people found out why they had been
getting bug reports from STiNG users that made no sense.


> 
> >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.
> 


	To state compatibility and provide it fairly well, one does not
assume that the programmer has gone out of their way to make a call
incompatible.  What would be the use of that, unless the programmer
specifically desired this incompatibility.  The incompatibility wasn't
always there, it was a latter addition. Which I must assume he buried the
announcement of at the bottom of a 24k post.



> 
> >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 !
> 

	Yes you did misunderstand me.  Lonny does not plan on fixing
AtarIRC to handle the STiNG CIB structure.


> 
> >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.
> 

	This is a funny twist.  Yes it was I who went into the STiNG code
and changed the CIB structure.  I admit it to all.


> >	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.


	I personally don't like it's method.  But from what you have
discussed in the past it sounds like it might be applicable in your
situation.   There are other ways around this that have been in use for
some time.

> 
> 
> >	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.
> 

	No, this is not the case.  A single IP number is not used across
all connections.  I'm not certain where the problem comes in with STiNG.
I have heard alternatively over time that the CIB is not actively used
internally in STinG and then that it is.  It might be too big of a problem
for you to fix.  And as I said if that's so then fine.  Don't fix it.  I
really don't care.


> 
> >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 !
> 

	But for how long will this remeain true?   I'm not saying that you
will be stealing peter's work.  How long before someone rewrites one of
the modules?  Could be never I guess...



	Are you happy now?

	Dan


---------------------------------------------------------------------------
To unsubscribe from this list, e-mail Majordomo@list.zetnet.co.uk
with the body of the message containing "unsubscribe Stik-Beta-Testers"
---------------------------------------------------------------------------

.
