NetMorph: Intuitive Mobile Object System and Applications

1. NetMorph An intuitive mobile object system andits applications January 30, 2003 Masashi Umezawa Kazuhiro Abe Satoshi Nishihara Tetsuya Kurihara

2. Table of contents • Problems of networking • NetMorph design and implementation • Conclusion and future plan

3. Problems of the present networking • Most network systems do not provide proper intuitive interfaces for us • Users have to acquire specific knowledge depending on various protocols • In many cases, users can only use prepared network applications • Developing their own distributed programs is tremendously difficult

4. What NetMorph aims at • Morphic and SqueakToys are great environment for developing computer literacy of non-technical people • But… • They do not support network applications • NetMorph provideslogical broad spaces, where users can create network applications freely

5. y y ： 0, 1 0, 1 1, 1 1, 1 ↓ ↓ ↓ ↓ 173.234.54.4 173.234.54.4 142.41.65.42 14 2.41.65.42 ・・ 0, 0 0, 0 1, 0 1, 0 ↓ ↓ ↓ ↓ 62.38.0.32 62.38.0.32 202.3.12.76 202.3.12.76 x x Basic concepts • Each morph has its own “network location” • The location of Morph is represented by the combination of 2D coordinates and logical network address • Morph can move toother desktops, simplychanging its locationvalues • Desktop relations aredefined by “WorldMap” 0, 0 0, 0

6. NetMorph script examples • MyCarwarp to • somehost • MyCar’s home • MyFriend’s address MyCar forward by 5MyCar turn by 5MyCar warp

7. Table of contents • Problems of networking • NetMorph design and implementation • Conclusion and future work

8. Migration (‘warp drive’) mechanism (1) • A Morph remembers a current desktop location for the later x y adjustments • The Morph serializes itself • The Morph sends the serialized data to the destination desktop by NMP (NetMorph Protocol) • The System invokes a ‘warpedOut’ event handling method that is usable for additional user defined behaviors

9. Migration (‘warp drive’) mechanism (2) 1 2 3 0101110 1010110 0100100 1001001 NMP y 4 0101110 1010110 0100100 1001001 warped out! x

10. Migration (‘warp drive’) mechanism (3) • A migration server (called Catcher) receives the serialized data and deserializes it to the Morph • The Catcher adjusts the Morph position • The system attaches the Morph to the destination desktop. The Morph begins to move in the new desktop • The System invokes a ‘warpedIn’ event handling method for additional user defined behaviors

11. 0101110 1010110 0100100 1001001 Migration (‘warp drive’) mechanism (4) 5 6 7 8 y warped in! x

12. Serialization in warp • SmartRefStream • Simple • Automatic class migration • But big and slow • We may develop a customized serializer… 0101110 1010110 0100100 1001001 0101110 1010110 0100100 1001001

13. Network communication between Morphs Original World Another World warp message returnValue message returnValue Joystick Proxy of Joystick

14. Finding a morph in networks (1) • Local ActiveWorld is searched. • If a Morph is found, the Morph is returned to the caller. If not, local cache is searched • If found in cache, a cached Morph proxy is returned. If not, remote servers that are registered in WorldMap are searched • If found, a Morph proxy is returned to the caller. If not, nil is returned

15. Finding a morph in networks (2) nil found proxy found not found found not found not found local cache WorldMap

16. Filtering the targets • AvailabilityChecker periodically checks if the registered entries of WorldMap are reachable • Finder only sees AvailabilityChecker’s available entry list Available Entry List

17. Finding a remote player in networks • Customized script generator • Now Players can always refer to other Players by identifier

18. Remote message sending between morphs aMorph(car) aNmDispacher 5. dispatch:to:selector: withArguments: 1. message 6. message 2. doesNotUnderstand: aNmMorphProxy 3. xxxCallWithArgumentsDispatch: target: aMorph(joystick) 4. callDispatch:to:selector:withArguments: aNmRemoteConnecter

19. WorldMap management • A MapServer provides a latest map data for NetMorph clients • Each NetMorph image periodically retrieves the CSV map data from a MapServer • We can edit a map datagraphically by using a WorldMapMorph

20. NetMorph protocol (NMP) • Compact • No tags • Binary • Fast • Connection pooling • Simple ‘NMP<version>’’<semantic>’’<command>’‘<encoder>’ *’<size>’!’ Binaries… Body Header

21. Live demos

22. Table of contents • Problems of networking • NetMorph design and implementation • Conclusion and future work

23. Conclusion • As you can see, NetMorph is fun! • In Smalltalk, everything is object • In NetMorph, everything is live network object • We had thought that it may be only a dream. But as the project proceeds, we’ve realized that it is possible in a few years • In spite of the naïve implementation, NetMorph works beyond our expectation! • Need to develop communities • More field tests • Utilize open source power

24. Field tests • We have not done any serious field-testing yet… • But, we are planning to perform a field test with children on Feb. 2nd 2003 at CAMP

25. The next goals • More tight integration with SqueakToys • Quality • Performance • Functionality • Slogan • “What can do in SqueakToys is what can do in NetMorph”

26. Developing communities • Helping Kyoto Alan Kay Project • Demonstration in OOPSLA 2002 • NetMorph Swiki • http://swikis.ddo.jp/NetMorph • SqueakMap • NetMorph will be available on SM in March 2003

27. Any questions?