-=> Quoting Paul Edwards to John Tserkezis <=-

Hello Paul,

 JT> I currently route 3:711/934.x traffic to your system, unless of course the
 JT> relevant point calls here and picks it up first.

 PE> I don't think that's possible with squish, so I presume you're using a
 PE> mailprocessor that doesn't pack things until the caller calls or
 PE> something? Or sends netmail uncompressed?  BFN.  Paul. 

 Yes and no.  Allow me to explain. :-)

 Ougoing netmail stays in separate packets, compressed or not, they stay
separate of echomail for each individual node.  During my poll to you, 934.0
traffic (echomail) goes as per normal, and any 934.x traffic that may exist
at that time also goes.

 If a point calls me direct, and has the 934.x AKA, and they happen to have a
netmail/packet waiting for them, it is not forced to stay here, it goes with
their poll.

 The only place 934.* traffic is NOT routed/sent to, is my normal uplink.  This
has been the case from when I became a node/point.  Since I polled you anyway,
I didn't see the point of routing 934 traffic the long way around.

 The only problem I see with this arrangement, is if a point does not call TML
anymore, and if anyone happens to send them netmail (934.x) and they don't
pick it up first, it will go to TML and stay there indefenitly.

 I could put them in my route file to keep individual traffic here, but as
some points call both, and I would rather not write "exceptions to the
rule"
entries in my route file unless there is a case where it would be more
efficient to do so.

John Tserkezis, Sydney, Oz. Fidonet: 3:712/610  Internet: jt{at}suburbia.com.au

... Psychic convention cancelled due to unforeseen problems.....
---