On Sat, 12 Jan 2008, Benjamin M. Schwartz wrote:
> Hash: SHA1
>
> Sjoerd Simons wrote:
>> Activities need to cope with people coming going anyway. If your in a mesh
>> only
>> environment, the mesh can be split into two or more parts at any point and
>> later on merge again. Salut will model that
On Sat, 12 Jan 2008 at 12:00:02 -0500, Benjamin M. Schwartz wrote:
> This is precisely what I am saying. Telepathy should only register a
> disconnect
> if there is no way to route between two XOs. The mesh system should be
> designed
> so that moving about within the mesh, or handing off betwe
On Sat, Jan 12, 2008 at 12:00:02PM -0500, Benjamin M. Schwartz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Sjoerd Simons wrote:
> > Activities need to cope with people coming going anyway. If your in a mesh
> > only environment, the mesh can be split into two or more parts at any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sjoerd Simons wrote:
> Activities need to cope with people coming going anyway. If your in a mesh
> only
> environment, the mesh can be split into two or more parts at any point and
> later on merge again. Salut will model that as people disconnecting
On Thu, Jan 10, 2008 at 02:29:15PM -0500, Benjamin M. Schwartz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Morgan Collett wrote:
> > We'll add some API to PresenceService and sugar.presence, and put some
> > signal into Sugar similar to the buddy-left signal to indicate you were
>
D'oh. Still recovering from a wicked cold.
2008-01-11T16:49:06 Bennett Todd:
> If so, you could use them to assign the lower 24
> bits of a 10/24 addr until you've shipped 16 million XOs,
10/8
Sorry.
-Bennett
pgpxodZ2p78Z8.pgp
Description: PGP signature
___
2008-01-11T13:41:44 Dan Williams:
> On Thu, 2008-01-10 at 14:00 -0800, [EMAIL PROTECTED] wrote:
> > why is it that the laptop needs to switch IP addresses?
>
> Because there are a finite number of IPv4 addresses.
I was dreaming about this last night. Do XO's have serially-assigned
numbers in them
On Thu, 2008-01-10 at 14:00 -0800, [EMAIL PROTECTED] wrote:
> On Thu, 10 Jan 2008, John Gilmore wrote:
>
> >>> IP addresses are going to change; that's a fact of life.
> >
> >> I know nothing about routing, but if a participant's IP address is about to
> >> change, perhaps the change should be bro
On Thu, 10 Jan 2008, John Gilmore wrote:
>>> IP addresses are going to change; that's a fact of life.
>
>> I know nothing about routing, but if a participant's IP address is about to
>> change, perhaps the change should be broadcast over the network, so that
>> Telepathy knows who to handoff the c
>> IP addresses are going to change; that's a fact of life.
> I know nothing about routing, but if a participant's IP address is about to
> change, perhaps the change should be broadcast over the network, so that
> Telepathy knows who to handoff the connection to.
To re-ground this discussion, if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Morgan Collett wrote:
> We'll add some API to PresenceService and sugar.presence, and put some
> signal into Sugar similar to the buddy-left signal to indicate you were
> disconnected, and ensure that the activity gets back into an unshared state.
>
>
[EMAIL PROTECTED] wrote:
> On Thu, 10 Jan 2008, Dan Williams wrote:
>
>>> In the server-based backend, an IP address change *will* cause a
>>> disconnect and reconnect. This is definitely unavoidable, since XMPP
>>> uses a long-lived TCP connection to the server.
>> IP addresses are going to chang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Williams wrote:
> It's not that hard to write an app that notices and handles IP address
> changes. Not handling this in apps that are written for or ported to
> the XO is just plain laziness. When porting or writing, you need to
> handle the alw
On Thu, 10 Jan 2008, Dan Williams wrote:
> On Fri, 2008-01-11 at 00:09 +, [EMAIL PROTECTED] wrote:
>> On Thu, 10 Jan 2008, Dan Williams wrote:
>>
In the server-based backend, an IP address change *will* cause a
disconnect and reconnect. This is definitely unavoidable, since XMPP
On Fri, 2008-01-11 at 00:09 +, [EMAIL PROTECTED] wrote:
> On Thu, 10 Jan 2008, Dan Williams wrote:
>
> >>
> >> In the server-based backend, an IP address change *will* cause a
> >> disconnect and reconnect. This is definitely unavoidable, since XMPP
> >> uses a long-lived TCP connection to the
On Thu, 10 Jan 2008, Dan Williams wrote:
>>
>> In the server-based backend, an IP address change *will* cause a
>> disconnect and reconnect. This is definitely unavoidable, since XMPP
>> uses a long-lived TCP connection to the server.
>
> IP addresses are going to change; that's a fact of life. T
On Thu, 2008-01-10 at 09:00 +, Simon McVittie wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 09 Jan 2008 at 22:17:18 -0500, John Watlington wrote:
> > We have a presence service which
> > provides a way for P2P applications to find
> > one another, even after the IP cha
On Thu, 10 Jan 2008, [EMAIL PROTECTED] wrote:
> for #2 the basic approach is the same as LVS uses in tunneling mode see
> http://www.linuxvirtualserver.org/VS-IPTunneling.html for a diagram and
> explination
>
> This is basicly what I was suggesting earlier, don't worry about the
> outbound tr
Simon McVittie wrote:
> On Wed, 09 Jan 2008 at 22:17:18 -0500, John Watlington wrote:
>> We have a presence service which
>> provides a way for P2P applications to find
>> one another, even after the IP changes.
>
> Presence Service isn't magical. If a laptop's IP address changes, in the
> link-lo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 09 Jan 2008 at 22:17:18 -0500, John Watlington wrote:
> We have a presence service which
> provides a way for P2P applications to find
> one another, even after the IP changes.
Presence Service isn't magical. If a laptop's IP address changes
On Wed, 9 Jan 2008, John Watlington wrote:
> On Jan 9, 2008, at 6:50 PM, Mikus Grinbergs wrote:
>
>>> Just switch off the Legacy IP, as we should have
>>> done months ago, and get on with making things work properly.
>>> Anything else is a distraction.
>>
>> I sympathize with how overworked OLPC d
On Wed, 9 Jan 2008, John Watlington wrote:
> On Jan 9, 2008, at 6:32 PM, [EMAIL PROTECTED] wrote:
>
>> On Wed, 9 Jan 2008, John Watlington wrote:
>>
>>> Sounds like you are volunteering to write that code.
>>> We need it by early next week.
>>>
>>> Yes, mobile IPv6 is one of our long-term soluti
On Jan 9, 2008, at 6:50 PM, Mikus Grinbergs wrote:
>> Just switch off the Legacy IP, as we should have
>> done months ago, and get on with making things work properly.
>> Anything else is a distraction.
>
> I sympathize with how overworked OLPC developers are. But a number
> of G1G1 systems are
On Jan 9, 2008, at 6:32 PM, [EMAIL PROTECTED] wrote:
> On Wed, 9 Jan 2008, John Watlington wrote:
>
>> Sounds like you are volunteering to write that code.
>> We need it by early next week.
>>
>> Yes, mobile IPv6 is one of our long-term solution possibilities.
>
> two things.
>
> 1. I didn't real
> Just switch off the Legacy IP, as we should have
> done months ago, and get on with making things work properly.
> Anything else is a distraction.
I sympathize with how overworked OLPC developers are. But a number
of G1G1 systems are getting into the hands of articulate net-aware
people. If
On Wed, 9 Jan 2008, Javier Cardona wrote:
>> The DHCP procedure currently being used only discovers
>> the nearest mesh portal when it is first run (DHCP_DISCOVER),
>> not when it tries to renew (DHCP_REQUEST). Furthermore,
>> as the address previously assigned indicates which mesh portal
>> was
John,
> The DHCP procedure currently being used only discovers
> the nearest mesh portal when it is first run (DHCP_DISCOVER),
> not when it tries to renew (DHCP_REQUEST). Furthermore,
> as the address previously assigned indicates which mesh portal
> was selected, it seems like we should always
On Wed, 2008-01-09 at 17:18 -0500, Michail Bletsas wrote:
> >
> > In the School Server case, using DHCP as the allowed us to collapse two
> > steps of the connection process into one. With the previous method, you
> > would have to _both_ find the MPP using the non-standard MPP discovery
> > meth
>
> In the School Server case, using DHCP as the allowed us to collapse two
> steps of the connection process into one. With the previous method, you
> would have to _both_ find the MPP using the non-standard MPP discovery
> method, and second do a DHCP run to get your address from the school
> s
On Wed, 2008-01-09 at 15:59 -0500, John Watlington wrote:
> On Jan 9, 2008, at 3:47 PM, Michail Bletsas wrote:
>
> >> The MPP discovery mechanism originally proposed worked great for
> >> getting
> >> packets out of the mesh through the shortest path. The problem was
> >> that outside of runni
On Wed, 9 Jan 2008, John Watlington wrote:
>> I completely fail to see why we need the DHCP server to get the IP
>> address
>> of the nearest MPP or get the optimal path to and from it.
>
> The MPP discovery mechanism originally proposed worked great for getting
> packets out of the mesh through t
On Jan 9, 2008, at 3:47 PM, Michail Bletsas wrote:
>> The MPP discovery mechanism originally proposed worked great for
>> getting
>> packets out of the mesh through the shortest path. The problem was
>> that outside of running NAT on each MPP, there wasn't a good way
>> to ensure
>> that pa
>
> The MPP discovery mechanism originally proposed worked great for getting
> packets out of the mesh through the shortest path. The problem was
> that
> outside of running NAT on each MPP, there wasn't a good way to ensure
> that packets sent to that laptop entered the mesh through the same M
> I completely fail to see why we need the DHCP server to get the IP
> address
> of the nearest MPP or get the optimal path to and from it.
The MPP discovery mechanism originally proposed worked great for getting
packets out of the mesh through the shortest path. The problem was
that
outsid
On Wed, 9 Jan 2008, John Watlington wrote:
>> In the case of the mesh portal (A NAT Internet Gateway in our case) we
>> need to get back the IP address of the gateway as well as DNS info.
>> A simple python server listening at a predefined port was providing
>> that.
>> That simple server has been
David Woodhouse <[EMAIL PROTECTED]> wrote on 01/09/2008 03:17:30 PM:
>
> On Wed, 2008-01-09 at 15:15 -0500, Michail Bletsas wrote:
> > Running application proxies on every XO that wants to act as a mesh
> > portal?
>
> Running NAT-PT. Since they're required to run NAT as it is anyway, that
> sh
On Wed, 2008-01-09 at 15:15 -0500, Michail Bletsas wrote:
> Running application proxies on every XO that wants to act as a mesh
> portal?
Running NAT-PT. Since they're required to run NAT as it is anyway, that
shouldn't be too much of a problem. And this 'mesh portal' mode isn't
something we rea
Dan Williams <[EMAIL PROTECTED]> wrote on 01/09/2008 01:29:27 PM:
> > I'm late to the party. How/who was it proprietary?
>
> The original method used UDP packets with a custom format. I wouldn't
> say "proprietary" so much as "non-standard" since the code that created
> the UDP packets was op
David Woodhouse <[EMAIL PROTECTED]> wrote on 01/09/2008 02:57:50 PM:
>
> NAT-PT and proxying should solve that problem relatively simply. I
> should investigate the implementation at http://tomicki.net/naptd.php
>
Running application proxies on every XO that wants to act as a mesh
portal?
M.
>
>
> The DHCP server was needed anyway. And to implement shortest path
> routing both for sent and received packets, we needed a mechanism for
> receiving an IP address that reflected the nearest MPP anyway (or use
> NAT, something we would like to avoid inside the school)
>
I completel
On Wed, 2008-01-09 at 14:43 -0500, Michail Bletsas wrote:
> > What do you propose to do about it? Throw away pointless engineering
> > into cobbling together some way of making Legacy IP work a bit better? I
> > seriously hope not. Just switch off the Legacy IP, as we should have
> > done months a
On Jan 9, 2008, at 2:55 PM, Michail Bletsas wrote:
> David Woodhouse <[EMAIL PROTECTED]> wrote on 01/09/2008 02:40:46 PM:
>
>
>> We can also
>> check the mesh path length to the origin of each RA we see, and
>> choose
>> the best one.
>>
>
> The way this was originally implemented in a way that
David Woodhouse <[EMAIL PROTECTED]> wrote on 01/09/2008 02:40:46 PM:
> We can also
> check the mesh path length to the origin of each RA we see, and choose
> the best one.
>
The way this was originally implemented in a way that can be used for any
"well defined" service (not just network gatew
On Jan 9, 2008, at 2:40 PM, David Woodhouse wrote:
>
> On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote:
>> Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this
>> problem. It's easy to discover the shortest way out of the mesh
>> (nearest mesh portal), but setting up the lar
> What do you propose to do about it? Throw away pointless engineering
> into cobbling together some way of making Legacy IP work a bit better? I
> seriously hope not. Just switch off the Legacy IP, as we should have
> done months ago, and get on with making things work properly. Anything
> else is
On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote:
> Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this
> problem. It's easy to discover the shortest way out of the mesh
> (nearest mesh portal), but setting up the larger mesh networkl
> infrastucture means you also need to pr
On Jan 9, 2008, at 2:08 PM, David Woodhouse wrote:
>
> On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote:
>>
>> Right now we have a problem with mesh portal discovery.
>>
>> The DHCP procedure currently being used only discovers
>> the near
On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote:
>
> Right now we have a problem with mesh portal discovery.
>
> The DHCP procedure currently being used only discovers
> the nearest mesh portal when it is first run (DHCP_DISCOVER),
> not when it tries to r
Because of RADV, IPv6 doesn't have that issue. The original
> mesh portal
> discovery method was
> proprietory but also extremely lightweight and did what it was
> supposed to
> do with minimal code.
>
> ...
On Jan 9, 2008 11:21 AM, Michail Bletsas <[EMAIL PROTECTED]> wrote:
> ...
> The largest issue is how wrong, ugly and painful is to use DHCP on a mesh
> network.
> Because of RADV, IPv6 doesn't have that issue. The original mesh portal
> discovery method was
> p
John Watlington <[EMAIL PROTECTED]> wrote on 01/09/2008 11:34:29 AM:
>
> Right now we have a problem with mesh portal discovery.
>
> The DHCP procedure currently being used only discovers
> the nearest mesh portal when it is first run (DHCP_DISCOVER),
> not when it trie
Right now we have a problem with mesh portal discovery.
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST). Furthermore,
as the address previously assigned indicates which mesh portal
52 matches
Mail list logo
