nebraska?

> On 3/20/10 4:35 PM, Marcus Denker wrote:
>>> So why does everyone ignore TeaTime? I admit I don't understand the
>>> internals, but it obviously *looks* like it could be the basis of
>>> Nebraska (or any other P2P solution).
>>>
>> Can you point me to a real good publication about it? I mean, a
>> *real* one?
>
> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some
> multiplayer game like sync scheme (at least the poor me understood when
> I saw the implementation ;-) ).

> On 3/20/2010 4:43 PM, Michael Rueger wrote:
>> On 3/20/10 4:35 PM, Marcus Denker wrote:
>>>> So why does everyone ignore TeaTime? I admit I don't understand the
>>>> internals, but it obviously *looks* like it could be the basis of
>>>> Nebraska (or any other P2P solution).
>>>>
>>> Can you point me to a real good publication about it? I mean, a
>>> *real* one?
>>
>> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some
>> multiplayer game like sync scheme (at least the poor me understood when
>> I saw the implementation ;-) ).
>
> Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications.
>
> That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250).
>
> Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here.
>
> As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides.
>
> Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward.
>
> BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works.
>
> Cheers,
>  - Andreas
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Good I like simple things. I'm really curious to learn it.
> So in a nutshell what is the idea of the synchronisation?
> How do do know which objects changed in an image?
>
> Stef
>
> On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote:
>
>> On 3/20/2010 4:43 PM, Michael Rueger wrote:
>>> On 3/20/10 4:35 PM, Marcus Denker wrote:
>>>>> So why does everyone ignore TeaTime? I admit I don't understand the
>>>>> internals, but it obviously *looks* like it could be the basis of
>>>>> Nebraska (or any other P2P solution).
>>>>>
>>>> Can you point me to a real good publication about it? I mean, a
>>>> *real* one?
>>>
>>> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some
>>> multiplayer game like sync scheme (at least the poor me understood when
>>> I saw the implementation ;-) ).
>>
>> Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications.
>>
>> That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250).
>>
>> Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here.
>>
>> As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides.
>>
>> Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward.
>>
>> BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works.
>>
>> Cheers,
>> - Andreas
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Tea Time is a great implementation of how to synch two replicas of the same world of objects.
>
> Replication of Computation vs Replication of Data!
>
> Islands encapsulate a world of objects, that whenever send each other messages make  the controller/router for that island to forward to all other replicated islands, the sent message (hence, computation vs data ( croquet vs Second Life ).
>
>
> And every island has a controller and a router with a message queue.
>
> Two replicas are consistent, because the same messages are "sent" in every replica.

>
> Every object ( TObject) tells its island that is has received a message.
>
>
> Fernando
>
> pd: I know a bit, because i've used Croquet for my master thesis.
>
>
> On Mar 30, 2010, at 10:44 AM, Stéphane Ducasse wrote:
>
>> Good I like simple things. I'm really curious to learn it.
>> So in a nutshell what is the idea of the synchronisation?
>> How do do know which objects changed in an image?
>>
>> Stef
>>
>> On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote:
>>
>>> On 3/20/2010 4:43 PM, Michael Rueger wrote:
>>>> On 3/20/10 4:35 PM, Marcus Denker wrote:
>>>>>> So why does everyone ignore TeaTime? I admit I don't understand the
>>>>>> internals, but it obviously *looks* like it could be the basis of
>>>>>> Nebraska (or any other P2P solution).
>>>>>>
>>>>> Can you point me to a real good publication about it? I mean, a
>>>>> *real* one?
>>>>
>>>> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some
>>>> multiplayer game like sync scheme (at least the poor me understood when
>>>> I saw the implementation ;-) ).
>>>
>>> Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications.
>>>
>>> That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250).
>>>
>>> Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here.
>>>
>>> As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides.
>>>
>>> Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward.
>>>
>>> BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works.
>>>
>>> Cheers,
>>> - Andreas
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> On 3/20/2010 4:43 PM, Michael Rueger wrote:
>> On 3/20/10 4:35 PM, Marcus Denker wrote:
>>>> So why does everyone ignore TeaTime? I admit I don't understand the
>>>> internals, but it obviously *looks* like it could be the basis of
>>>> Nebraska (or any other P2P solution).
>>>>
>>> Can you point me to a real good publication about it? I mean, a
>>> *real* one?
>>
>> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some
>> multiplayer game like sync scheme (at least the poor me understood when
>> I saw the implementation ;-) ).
>
> Actually we didn't. TeaTime (as conceived by David Reed) consisted of
> two separate ideas, namely that of a world synchronization protocol
> and that of a P2P network protocol. When David Smith and I implemented
> the version we shipped in Hedgehog we dropped the P2P network protocol
> part and only concentrated on the synchronization aspect which
> resulted in *major* simplifications.
> [...]
>
> Coincidentally, I am toying regularly with the idea of using an even
> more simplified version of TeaTime to do something like Nebraska.
> Might get around to it one of these days, it's actually straightforward.
>
> BTW, it's a misconception to think TeaTime is something complicated.
> Complicated things don't work. Simple things do. TeaTime is actually
> VERY simple. That's why it works.