Return-Path: <perot@pallas.amp.uni-hannover.de>
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3])
	by hugin.oden.se (8.8.5/8.8.5) with SMTP id XAA24248
	for <dlanor@oden.se>; Sun, 26 Jan 1997 23:14:35 +0100
Received: from pallas.amp.uni-hannover.de by mgate with SMTP (PP);
          Sun, 26 Jan 1997 23:13:57 +0100
Received: by pallas.amp.uni-hannover.de (AIX 3.2/UCB 5.64/4.03) id AA17100;
          Sun, 26 Jan 1997 23:11:25 +0100
Date: Sun, 26 Jan 1997 23:11:04 +0100 (MET)
From: Peter Rottengatter <perot@pallas.amp.uni-hannover.de>
To: Ronald Andersson <dlanor@oden.se>
Subject: Re: [3] Another success : UDP
In-Reply-To: <199701250048.BAA01195@hugin.oden.se>
Message-Id: <Pine.A32.3.91.970126223050.17530M-100000@pallas.amp.uni-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 41cc32b21cea82c5495e43bef030d1ff


On Sat, 25 Jan 1997, Ronald Andersson wrote:

> >> I guess I'll have to modify the routing anyway, so please specify how.
> >
> >Assign two IP addresses, say 192.68.0.1 for your Falcon's port, and 
> >192.68.0.2. for your ST's port. Thus enter 192.68.0.1 into the STiK Port 
> >Setup on the Falcon, and 192.68.0.2 on the ST. Use 255.255.255.0 as net 
> >mask in both cases, and, say, 1500 as MTU. You can use the same routing 
> >table for both machines, if you only write one line
> >
> 
> The subnet mask below is not what you specified for the table in your file
> ESTABLIS.TXT which used 0.0.0.0 instead.  Could that be it ?  (I'll try)

It should not. See below.


>                 ||| ||| ||| |
>                 ||| ||| ||| |
> >0.0.0.0        255.255.255.0        Midi      0.0.0.0
> >        ^^^^^^               ^^^^^^      ^^^^
> >        Use TABs here.

Did I write this ? That's nonsense ! I must have been drunk ! ;-)

The IP address of the packet to be routed is ANDed with the netmask
(255.255.255.0) and the result compared to the template (0.0.0.0 here, 
which is nonsense). So equality were achieved only for IP addresses 
0.0.0.x, where x is any number up to 255. Those IP addresses aren't 
valid. Use instead the entry 192.68.0.0 here.

So sending a packet to 192.68.0.2 from the Falcon lets STiK AND the 
address with 255.255.255.0, which then results in the correct template, 
thus the Midi port is selected for sending the packets. In fact, any 
packet with IP addresses 192.68.0.x is routed to the Midi, which lets 
you reach third machines that are connected to your ST's serial port, 
for instance. But then you must have corresponding entries in your ST's 
routing table.

Sorry, if I really wrote the quoted line above, that cannot work.


> >into the file. Click 'Reload Routing' and 'Active' to be selected, and 
> >click OK. If you've clicked STiK active in STiK Internals, then you're 
> >connected now. Now start ping on your Falcon, and try
> >
> >a) 127.0.0.1        Packets are echoed by the Falcon's IP
> >b) 192.68.0.1       Packets still stay inside the Falcon
> >c) 192.68.0.2       Packets now go to the ST and are echoed there.
> >
> >
> >> >If nothing of all this helps, I'll send you a special version of 
> >> >SERIAL.STX which prints to the screen what it sends out. Then we can 
> >> >check what gets send, and see if it is wrong.
> >> >
> >> That would be a very awkward way of testing though.  Why not 'sprintf' to a
> >> RAM buffer instead, and then write that buffer to disk.  This way I could
> >> send you the results in meaningful form.  A bit like LOGSTIK results I mean.
> >
> >You're right, but it's more effort ;-) I'll do it like you suggested. 
> >If you run MagiC on your Falcon I can even make it write from interupt, 
> >not needing the RAM buffer.
> 
> Are you sure...?  I know bios and xbios are allowed in MagiC interrupts,
> but I did not think gemdos was too.  I had a quick look in my docs now,
> and though there was an entry on reentrancy, I could not find  anywhere
> the explicit permission to use them in interrupts.  Hopefully you're right.

In MagiC it works. Actually with older TOS I used to assume everything 
that isn't documented does not work. With MagiC I assume that what is not 
documented to bomb, works. And this works rather well ;-) Of course it's 
only for quick'n dirty things.


> Ok, now for some news that I guess you will not like.  It appears that
> Martin has found a way to protect against crashes during initialization
> of 'custom' modules as well.  I'm not really surprised, because I had

A way that works with 68000 CPUs in a similar quality as the Pexec does ? 
Of course it's easy with 68030's, using their PMMUs.


> [ ... lots of sophisticated suggestions deleted ... ]
> 
> The magic recognition is done by testinging a 'long' or two in what would
> have been the program flags, which assures a sufficient difference from
> the real executable format so that no program launcher will swallow it.
> Finally, the Pterm/Ptermres calls must be replaced simply by RTS, with d0
> carrying a long result value.  If negative this flags an error, if zero
> this means success but that the whole module must stay resident, and if
> larger than zero it means success with an ASM module needing only to keep
> so much RAM as D0 says in staying resident.
> 
> The RAM block is then shrunk with Mshrink, which under these particular
> circumstances will work fragment-free on all existing TOS.
> 
> The end result of this is that all necessary module changes are to create
> that dummy startup object file, and changing the Pterm/Ptermres calls.
> 
> In most essentials you still have a system very similar to the present,
> but without using Pexec, so nobody has anything to complain about.

In a way this is comedy. We spent so much time discussing ways to avoid 
duplicate code, now we're duplicating the OS Pexec code.


> What do you say ?
> Should we go for this ?

It could be a way to go. Let me think about it. What I still wonder 
is why don't we simply use the OS's Pexec. People who are advocating 
efficiency force us to do so. It's insane, but we might not have any 
choice.

I'll tell you soon.


Cheers  Peter

---------------------------------------------------------------------
   Peter Rottengatter             perot@pallas.amp.uni-hannover.de
---------------------------------------------------------------------

.
