For distributed computing project course Technion, March 2011 Alex Dvinsky

What is it? An IP based networking library Targeted for networking in groups Allows building custom protocol stacks Has lots of layers to build from Is multi-platform J2ME Android JSE.Net Compact Framework

Why do we need it? Allows us to focus on the logic of our application, rather then implementing commonly needed stuff Dealing with network issues can be non trivial Limiting network spec of some platforms Atop of it - poor implementation of the spec by some vendors Same application code on supported platforms Less threading concerns

What do we get from it? Discovery, View Management & Failure Detection Inconsistent views Consistent views Broad/Multi casting Message reliability (incl. multi/broadcast messages) Ordering Sender FIFO Total Fragmentation/Reassembly Flow control JiBX generated classes serialization support … more …

Where do we get it? SVN repository: Username (mail): Password: DslProject Project GCFrameworkDist Branches folder contain past versions Trunk folder is the current state, bug fixes and new features will be put here All distributions also contain sources

Where do we start? … With development environment setup Mobile development is somewhat different from development for PCs There are more (interconnected) tools Less standards Less documentation Much less stability Harder –to-impossible on-device debugging Networking on devices and emulators does not always come out of the box I’ll give you the initial installation instructions and share what experience I have, but prepare to Google a lot

Where do we start? (Cont’d) In the same repository there’s a sample project GCChatCLI It’s a JavaSE command line interface for a basic, J2ME compatible, chat core Shows creation, initialization and destruction of a protocol stack Message and view change handling Android UI is to follow shortly Is somewhat tricky both to build and run I’ll send instructions for this too But gives a nice example of building multi-platform app.

Documentation? No external documentation  Many layers have a JavaDoc header explaining their use, assumptions, suggested placement within a stack and other properties Please contact me with any questions/requests/bug suspicions

Some overview The usage of the middleware is by building custom protocol stack(s) The stacks consist from layers Communication between layers is done by handling events Bottom layer is always a network layer – the one that sends and receives data on sockets Top layer is always an application layer – implemented by app. developer. Sends messages and may respond to some events In most cases lower layers of the stack serve those above them, but there are exceptions All communicating hosts must run with identical stacks

Some overview (cont’d 1) Most of the layers in stack handle their events in a single, designated, thread and thus are not built to be multithreaded This thread is to be protected from application, there’s a special layer for this as well

Some overview (cont’d 2) As messages propagate through the stack, layers add headers to it, if the message goes down and extract them if the message goes up Every layer on sending host communicates with very same layer on receiving hosts through its header only Every message has an ID that identifies it Every received message contains information about who its sender is

Some overview (cont’d 3) In J2ME, there’s a very limited set of platform-supplied data structures. The middleware contains adapted to J2ME versions of most commonly used Java data structures (from “GNU Classpath”) All layers’ headers are defined by.XML files, those files can be “compiled” to Java by external tool – JiBX; and for the classes JiBX produces, middleware tools can generate serializers, that handle integration and extraction of these headers from messages. Though built for internal uses, application developers can benefit from these tools

Some pitfalls Java versions are not fully compatible with each other J2ME Android JSE When building a multi- platform app, consider finding the largest common part and put it in “core” project The list of intended supported platform dictates what java version the “core” must be compatible to

Some pitfalls (cont’d 1) In mobile applications you need to explicitly request permissions for multiple operations (declare you use the functionality), especially such as network or disk/flash access The J2ME installed on win mobile phones we have is called “Jblend”. It’s impossible to have server TCP sockets in it, thus it the middleware can only be used with UDP In Jblend it’s also impossible to have more than one server UDP socket and more than one client UDP socket opened at the same time, thus only one stack can be used per application and UDPNetworkLayer must be instructed to always close its client UDP socket

Some pitfalls (cont’d 2) In JBlend it’s also impossible to have class implementing non-public (package-visible) interface. It just fails to run There’s another version of J2ME you can install on those Win mobile phones, called “Jbed”; don’t, - it’s even worse and doesn’t support server sockets of any kind In Android, it’s important to specify settings like “layout_width” and “layout_height” event if it seems to make no sense. Otherwise it just won’t work with no clear error message

Some pitfalls (cont’d 3) Firewalls block messages You’d be surprised to know how often I fell to this one If testing on emulators, it’s important to make sure they can talk to each other Android emulators can’t without specific configuration. More about it in installation instructions J2ME emulator, at least the one from Samsung SDK, just use JavaSE for all its “emulation” including sockets. Thus, it’s both unclear which interface is used and not possible to have two running instances be configured to the same port VMs can help here