Rochester Institute of Technology

1. Rochester Institute of Technology Distributed ComputingwithSmall Mobile Wireless Devices Alan Kaminsky/Hans-Peter Bischof Information Technology Laboratory/CS Department Rochester Institute of Technology ark@it.rit.edu/hpb@cs.rit.edu

2. The Problem and the Opportunity • The Anhinga Project • Part 1: Distributed Services • Part 2: Distributed Collaboration • First Steps

3. The Changing Computing Milieu (1) • Yesterday/Today: large sessile wired hosts

4. The Changing Computing Milieu (2) • Tomorrow: small mobile wireless devices Bluetooth™ is a trademark of Telefonaktiebolaget LM Ericsson.

5. Device Characteristics • Compared to standard PCs/workstations,small mobile wireless devices have . . . • Slower CPUs • Smaller memories • Slower network connections • Limited input/output capabilities • Heterogeneous operating environments • Transitory interconnections • Huge applications won’t work • Distributed applications are needed

6. Infrastructure Barriers • The sessile infrastructure: • Server machines, client machines, wired network • Client-server architectures • Mobile device = just another client machine • The problem: • Servers crash, networks go down • Mobile devices go where there’s no wireless access • The opportunity: • Ad-hoc networks solely of mobile devices • Peer-to-peer architectures with mobile devices • “No Sessile Infrastructure”

7. 10 meters Wireless Personal Area Networks • The “Personal Bubble”

8. Missing Technology • Low-level technology: present • Wireless local area networks • IEEE 802.11 (Wireless Ethernet), Bluetooth • Java: write once run anywhere • Java 2 Micro Edition (J2ME) • High-level technology: not there yet • Mobile device network routing protocols: not finished • IETF’s MobileIP, MANET • Distributed middleware standards: too big • CORBA, Jini Network Technology • There is a lack of distributed middleware designed specifically for ad-hoc networks of mobile devices

9. The Anhinga Project The Anhinga Project

10. Purpose and Goals • Purpose • “Develop an infrastructure for distributed communication and collaboration using small mobile wireless devices, thus realizing such devices’ latent potential for building ad-hoc peer-to-peer distributed applications.” • Goals • Distributed services infrastructure • Distributed communication & collaboration infrastructure • Proof-of-concept applications • Device-to-device instant messaging • Device-to-device collaborative groupware • Use of Anhinga/Java Space

11. What’s an Anhinga? Photograph courtesy Philip Greenspun http://www.photo.net/philg/

12. Part 1: Distributed Services Part 1: Distributed Services

13. Federated Service Architectures • Hardware? Software?  Service • Everything is a service • Printer  Print service • Scanner, Camera  Image capture service • CPU Server  CPU service • E-mail  E-mail service • Federated services • Dynamic discovery • Ad hoc connections • Limited CPU power, memory, bandwidth • No sessile infrastructure

14. Java • Write once, run anywhere • Supported on small mobile wireless devices • Remote method invocation (RMI) • Moveable objects — state & behavior • MarshalledObject = serialized state + codebase URL • Ideal for programming a heterogenous collection of devices Java™ is a trademark of Sun Microsystems.

15. Jini Network Technology • Infrastructure for a federated service architecture • Service interfaces — to define services • Service proxy objects — to use services • Lookup Service — to find services • Discovery protocol — to find the Lookup Service • Join process — to register services Jini™ is a trademark of Sun Microsystems.

16. Java and the Device Space • Great Big Java • Java 2 Standard Edition (J2SE) • Middle Sized Java • Java 2 Micro Edition (J2ME)Connected Device Configuration (CDC) • Wee Little Java • Java 2 Micro Edition (J2ME)Connected Limited Device Configuration (CLDC)

17. J2ME Profiles *Mobile Information Device Profile

18. J2SE J2SE J2ME CDC J2ME CDC Jini Runs Here Jini Client Jini Service

19. J2SE J2ME CLDC J2ME CLDC J2ME CLDC Jini Doesn’t Run Here Jini Client Jini Service

20. Why Jini Doesn’t Run There • J2ME CLDC lacks . . . • Security manager • User-defined classloaders • Reflection • Object serialization • Marshalled objects • . . . therefore cannot access the Lookup Service • It also lacks Remote Method Invocation (RMI)

21. Getting Jini to Run There (1) • Jini Surrogate Project • Jini WirelessDevice Project • “No Sessile Infrastructure” Camera PC/Workstation Cellphone

22. Getting Jini to Run There (2) • Anhinga Project Wireless Camera Cellphone

23. Anhinga Project Part 1 Tasks • Develop extensions to J2ME CLDC • Lightweight classloading, security, serialization, RMI • Support for mobile objects in limited device memory • Bluetooth support • Develop Jini Mobile Edition (JiniME) • Variation of Jini for J2ME CLDC devices • Service discovery with self-hosted Lookup Services • Bridge to a sessile Jini federation • Environment • Linux PDAs with Bluetooth modules • Palm PDAs with Bluetooth modules

24. JiniMEBridge Jini Federation Anhinga Project Part 1 Results JiniME Federation

25. Part 2: Distributed Collaboration Part 2: Distributed Collaboration

26. Communication Patterns • Service interactions • One-to-one • Collaborative applications • Many-to-many (M2M)

27. Network Protocols • TCP/IP was designed for one-to-one communication between distant sessile hosts • IP multicasting was designed for one-to-many communication • The IETF is trying to shoehorn mobile devices into a sessile mold • MobileIP: Make IP addresses work for mobile devices • MANET: Make IP routing work for ad-hoc networks • Need new protocols specifically designed for M2M communication in ad-hoc networks of proximal mobile devices

28. Distributed Programming Paradigms • Shared memory: doesn’t match hardware • Message passing: too complex • Tuple space: just right • Invented by David Gelernter, Yale U. • Linda, JavaSpaces JavaSpaces™ is a trademark of Sun Microsystems.

29. 4. Take 2. Write tuple 1. Read 3. Read template Tuple Space Abstraction Device Device Tuple Space Device Device

30. Anhinga Project Part 2 Tasks • Develop M2M communication protocol • Designed specifically for ad-hoc networks of proximal mobile devices • Don’t rely on addressing individual devices • Work over various physical layers (802.11, Bluetooth) • Develop distributed tuple space implementation • Tuple resides in writing device • Tuple transferred to reading or taking device • M2M protocol announces all tuple space operations • Hashing used for tentative template matching

31. Security Issues • Unauthorized users • Authentication provided by secret authentication keys • Authentication = authorization in this case • Passive intruders (network sniffers) • Foiled by encrypting all packets • Active intruders (network spoofers) • Replay attacks foiled by challenge-response protocol

32. Design Idea Design Idea…

33. Application Layer

34. Distributed Infrastructure I

35. Distributed Infrastructure II

36. Java Layer I

37. Java Layer II

38. Native Layer

39. Questions? ???????????

40. Thanks Thanks Danke