re Transact and peer to peer.

[Robert Edwards]

OK, I did get a response back from a very helpful customer care guy
(I won't publish his name). He informs me that peer-peer will be implemented
in December (didn't mention which end of the month).

Andrew is correct in his description of how it will work. What he failed to 
mention, of course, is that a Linux box can quite happily maintain two or 
more PPPoE connections concurrently, so it will be possible for Linux users 
to simultaneously be connected to their ISP and to one or more peers. Sorry 
for those not running Linux (or other sensible O/Ss).

Cheers,

Bob Edwards.

> 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&pageN
>ame=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