re Transact and peer to peer.

andrew at bishop.dropbear.id.au andrew at bishop.dropbear.id.au
Thu Oct 25 07:54:52 EST 2001


On Thu, 25 Oct 2001, Andrew wrote:

> Hi,
>     The problem with peer to peer networking and transact can't be
> solved that easily.  Each connection is created with an Authentication
> handshake (which is handled by the ISP of choice).  Therefore if we
> wanted any transact client to send data directly to another one without
> being charged, ALL the ISP's (I believe only two at the moment, but
> growing) would have to agree on this.

Well, if the isps involved decided to allow their transact customers free
internal traffic, that would also solve the problem, kinda... (everyone
would still need to get an isp, and pay for some minimum package, even if
they only wanted internal traffic).  However, the transact network, as
originally advertised, was to provide unmetered internal traffic, from any
host to any other - and an isp would just be another host on the network
as far as transact was concerned, one that just happened to route internet
traffic to/from its customers.

I understand that transact's network configuration doesn't support that
idea directly.  They just have one big router, which talks PPPoE to each
customer, and also talks to each isp.  All the routing it does is to work
out which isp each customer should be connected to, and pass all their
traffic over to the appropriate isp's equipment.

When I asked them about this a couple of months ago (I've been on transact
for 5 months now), I was told that the way they planned on implementing
local connections (one customer to another, no isp involved) was to set up
what look like, effectively, another isp.  To connect one customer to
another, both would start up connections to this 'loopback' isp, which
would assign its customers IP addresses from one of the private subnets,
and only route traffic within that subnet (i.e. between transact
customers), with no upstream connection to the 'net at large.

So, when a customer "dials up" through transact, they choose who to
connect to.  If they connect to the loopback thingy, they can talk to
others connected to said loopback thingy, but nobody else.  If they
connect to their isp, they can talk to the internet, but they'll be paying
their isp to do so.  (and hopefully it would be possible to connect to
both "isps" simultaneously).


For people who want to hassle them about getting this implemented (as
stated in earlier posts, they don't even have a timeframe for this yet),
you'll probably have to get past a number of salesdroids who don't have
any idea what you're talking about.  They seem to have stopped advertising
local connectivity as a feature, but there's still a mention hidden away
in one of their 'technical faqs', at
http://www.transact.com.au/default_Graph.asp?sectionName=HomeServices&pageName=techfaq.asp&textonly=yes

This has the advantage of making yours a 'techincal question', and so make
their decision to put you through to someone with actual technical
knowledge easier. :)

----
I believe that our account will be assigned a static 10.x.x.x IP adddress.
If so, what security will be enabled within that WAN?

Yes, you will get a 10.x.x.x address within the TransACT network, but we
expect that some ISPs will also offer permanent real-world IP addresses to
customers who want to be visible to the world.
[...]
----

Other phrases to throw into your conversations include "community
intranet", "albatross" and "doomsday device".

Andrew





More information about the linux mailing list