<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Wed, 12 Aug 2009 15:54:29 +0100
From   : michael.firth@... (michael.firth@...)
Subject: Econet <> Ethernet

> -----Original Message-----
> From: 
> bbc-micro-bounces+michael.firth=bt.com@... 
> [mailto:bbc-micro-bounces+michael.firth=bt.com@...
> .uk] On Behalf Of Rob
> Sent: 12 August 2009 15:31
> To: BBC micro mailing list
> Subject: Re: [BBC-Micro] Econet <> Ethernet
> 
> On 12/08/2009, michael.firth@... <michael.firth@...> wrote:
> > You might also want some other form of persistent ID in 
> these messages, so
> > that more than one gateway can sit behind the same NAT 
> device (and hence IP
> > address) - I'm not completely sure why you'd need this, but it seems
> > sensible to make the protocol capable of supporting it.
> 
> It might be easier to make it a configureable port number,
> particularly for incoming connections that have to be forwarded by a
> cheap home router which can generally only cope with one onward
> destination per port ..

That might be the other way of doing it, then the binding becomes an IP/port
pair.

> 
> >
> > Something like that would also help with an accept / reject 
> decision - if
> > people agreed on an ID range then you could build Econet 
> "VPNs" that would
> > talk to each other, but reject messages outside the ID range.
> 
> What about some sort of identification code or password that needs to
> be quoted on a registration in order for it to connect?  That would
> stop just anybody connecting into the virtual econet.  md5(password) ?
> 
That sounds like a good plan, if the hardware can do md5.

> Also, what happens if gateway A and gateway B both connect to gateway
> C, and the hosts behind A want to talk to hosts behind B - does
> traffic have to go via C, or should there be a way for C to inform A
> and B about each other?
> 
Generally what happens with tunnels is that traffic will go via C, unless
a direct
tunnel is also configured between A and B, when the traffic would go direct.

You've now built yourself the situation that classic routing protocols (OSPF
and so on)
have to work hardest to solve - as this scales, what's the optimal route
to host X?

To allow that to work effectively, you'll also need to have some concept
of weighting, otherwise,
consider a network like:

A-----B
|     |
|     |
C-----D

Potentially you might have problems routing traffic efficiently between the
corner sites, particularly if the links between the four sites are not all
the same speed.

It all depends how complex you want to make things...

Regards

Michael
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>