An ios Static Library for Service Discovery and Dynamic Procedure Calls

Transcription

1 An ios Static Library for Service Discovery and Dynamic Procedure Calls Arnav Anshul Department of Engineering. Arizona State University Polytechnic Campus. Abstract - Remote procedure call is one of the popular methods employed when designing distributed applications. The existing RPC implementations are, however, unavailable on a mobile platform; with Mac OS X supporting Vending but not making it available on ios and Java supporting Remote Method Invocation but that is unavailable on Android, two of the most dominant operating systems on the mobile platform. With the standards of processing power and features available on the mobile devices improving significantly, mobile applications might do well with the ability to discover and bind dynamically to local information servers. The following paper describes a framework developed for the ios platform that brings most of the features of the paradigm to the mobile platform. Index Terms Remote procedure calls, ios, mobile applications, dynamic procedure call, dynamic service discovery. I. INTRODUCTION A remote procedure call (RPC) is an inter-process communication paradigm that allows a program to execute a procedure or a subroutine remotely in the address space of another program on a shared network without being required to provide specific details for the remote interaction over the network (Wikipedia n.d.). This essentially implies that the target application essentially uses the same syntax whether the subroutine is local to the executing program or remote. This setup sets the groundwork for simplifying the creation of distributed applications since the underlying framework handles all the relevant network communication for the application. When the application in question uses object oriented principles, the technique is called remote invocation or remote method invocation. Distributed systems on a mobile platform have, however, been limited to REST (Representational State Transfer) or SOAP (Simple Object Access Protocol) API invocations that essentially imply exchange and interpretation of text based data (XML or JSON formats) to conveniently interpret and display information. Being able to replicate a module akin to Remote Method Invocation in JAVA or Vending in Objective-C, available for use on JVM or Mac OS X environments respectively, would allow applications to interact with each other on an object level thereby aiding developers of interpreting the transmitted message and making direct method calls on objects. The use of the developed framework would allow mobile application developers developing ios applications the discovery of remote services, something that is not supported by either Vending or Remote Method Invocation, and directly calling remote methods. The implementation would allow ios applications to discover services, connect to one of the available service providers and call methods on the server by creating a dedicated method object. The applications would be able to publish their own services dynamically as well. The intended framework would, therefore, bring forth a framework that would provide "Vending" (available on Mac OS X as mentioned above) like functionalities (allowing method calls for a given

2 client on the server in a distributed application environment) to ios based applications. II. RELATED WORK The availability of a framework or an implementation for distributed objects has not been afforded on the popular mobile platforms like ios or Android. The closest framework available on ios is the Game Kit framework. This framework allows for the serialized data to be uploaded to the Game Center servers that maintain the state of the machine. Various clients use this shared data to display and update information. A Game Center application model is a very secure but is not devoid of its concomitant limitations. Use of this model allows devices to interact via internet only. Therefore, the ability to publish services on a local network is expected to improve the performance of the application. The use of Game Center also requires all the users willing to use a particular application to have a Game Center account. This could be seen as futile effort when looking at some of the application domains where this framework could be used. The developed framework would also provide its users/developers to have a greater control over the behavior of the applications. The lack of any open-source frameworks implementing a distributed object model for mobile-based platforms also provides motivation for work in this domain. III. APPROACH Background In the Mac OS X environment, distributed objects operate by making public an object to which other client processes can connect. Once a connection is made, the client process is able to invoke methods of that object as if the methods existed on the client process itself. These methods are then actually executed on the server and the result of the execution (response) is sent back to the client. Implementation Methodology Bonjour The underlying framework used to build upon, while developing this framework is called Bonjour. Bonjour is an open protocol for zeroconfiguration networking over IP submitted to IETF (Internet Engineering Task Force) (Apple Documents n.d.) by Apple. Bonjour was derived from the work of ZEROCONF Working Group, a part of IETF. The work included requirements and proposed solution for three areas in this domain: Addressing (allocation of IP addresses to hosts) Naming (using names instead of IPs to refer to hosts) Services discovery (automatic discovery of services available on a network) Bonjour proposed the following implementation to meet the above criteria: Addressing: This is solved by self-assigned link local addressing (a range of addresses reserved for the local network, typically a small LAN) Naming: The proposed solution involved the use of mdns (Multicast DNS) where DNS format queries are sent over the local network using IP multicast. This allows for the lack of a single DNS server with global knowledge since all the queries are multicast. Service Discovery: This allows an application to find all the available instances of a particular kind of service to maintain a list of named services. Publishing a service To publish a service, applications or devices must register the service they intend to publish with a Multicast DNS responder. When a service is registered, three related DNS records are created: 1. a service record (SRV) 2. a pointer record (PTR) 3. a text record (TXT). The SRV record maps the name of the service instance to the information needed by a client to actually use the service. It contains the following information Host name Port number The host name is the domain where the service can currently be found. The services are identified by host name rather than by a single IP address since it could be the case that the service is multi-homed

3 i.e. hosted by more than one IP address. The port number identifies the UDP or TCP port for service. The PTR records enable service discovery by mapping the type of the service to a list of names of specific instances of that type of service. This record adds another layer of indirection so services can be found just by looking up the PTR records labeled with service type. The TXT record has the same name as the corresponding SRV record and can contain a small amount of additional information. E.g. a chat program could contain the information regarding the availability of a user. To discover services, an application performs a query for PTR records matching a service type as specified by the application. The Multicast DNS responders running on each device return the PTR records with the service instance name. Figure shows a client application looking for services of type _chat._tcp. Figure 2 Discovery of services Bonjour provides two classes, the NSNetService and the NSNetServiceBrowser that are a part of the Foundation framework in Cocoa. NSNetService objects represent instances of services published and discovered by a client. The NSNetServiceBrowser represents a browser for a particular type of service and is used to discover the services publish on the network. Figure 1 Querying for services To resolve a service, an application performs a DNS lookup for a SRV record with the name of the service and gets the domain and port for the service. The figure below shows the response that a client device would receive upon querying for services on a network. Figure 3 Architecture of Bonjour Framework Framework The developed framework uses Bonjour as the foundation for setting up network communication between devices. The framework can be broadly categorized into four sections:

4 Network Interface Classes: This set of classes set up the sockets and handle communication between devices. These are the classes that basically implement the Bonjour framework. None of the classes listed below are visible to the application that use the framework. The framework provides a higher level of abstraction that simplifies creation of the client-server model and is described in later sections. AppConfig: This is a singleton class that creates a single instance of a service that can be created and published. The instantiation of the single object of this class is placed in block that essentially implies a thread safe block (@synchronized is a tool provided in Objective C to create mutex locks on the fly). This ensures that multiple instances of the service are not created if it is being instantiated in a multi-threaded environment at multiple places. Connection: The Connection class handles all the socket connections that need to be created and maintained during a session between the client and the server. An object of the class can be initialized using a host name and port number or by the name of the NSNetService that a given client intends to connect to. If it is initialized using a net service, the host name and the port number values are retrieved from the NSNetService object and used. Once initialized the connect method of the instance of Connection is called that resolves the host name and port number and creates a socket connection to the host. The Connection class also has a couple of methods to write to and read from the stream buffers of the socket. For the incoming data, the method readfromstreamintoincomingbuffer copies the data from the stream into a data buffer that is of NSMutableData type and then invokes the callback method with the aforementioned NSMutableData object created as a parameter. For the outgoing data, the Connection class provides a method called sendnetworkpacket that receives an object, serializes it into an NSData object and then copies the data to the outgoing data buffer. The method writeoutgoingbuffertostream writes out this data in the buffer to the outgoing stream of the socket. ConnectionDelegate: This protocol requires any class instantiating a connection object to implement the following three methods, that would serve as a callback for the Connection class, namely: o connectionattemptfailed:(connecti on*) - To inform the delegate of a failed connection attempt for the Connection object passed as a parameter. Possible reasons could be inability to resolve host name and port number. o connectionterminated:(connection *) - To inform the delegate that the connection was terminated for the Connection object passed as the parameter. o receivednetworkpacket:(nsdata*) viaconnection:(connection*) - To inform the delegate that some data was received for a given Connection object that was passed as a parameter. Server: This class handles the methods used to setup a server, publish a service and listen for incoming network connection requests for the published service. The class that creates the instance of Server calls the method startwithservicetype:(nsstring *) that in turn calls the createserver method followed by the method publishservicewithtype:(nsstring*). The createserver method creates a listening socket for incoming connection requests. The kernel assigns the port number on which the service is to be published and this port number is recorded for use when the service is to be published. Finally, a runloop is created, which is essentially a

5 background thread, on which the listening socket listens for incoming connections. The publishservicewithtype:(nsstring *) method receives the type for the service to be published which is of the format _<type name>._<protocol name>., e.g. _chat._tcp. (As specified by the Bonjour specifications). This is the type name that is used by the client application when it tries to discover services on the network. To stop a server the method stop is provided that stops the net service followed by terminating the server and releasing the socket thereby freeing up the port assigned to the application by the kernel. ServerDelegate: This protocol requires any class instantiating a server object to implement the following two methods, that would serve as a callback for the Server class, namely: o serverfailed:(server*) reason:(nsstring*) - The Server class above is a delegate to the NSNetService object that is created to publish a service. The most probable case for failing to publish a service is that there is already a service published with the same name. o handlenewconnection:(connection *) - This method is called by the Server object on the assigned delegate to inform that a new client connected to the server. ServerBrowser: This is the class that is used to search for services already published on the given network. It is instantiated with the <service type> that is being searched for. Once all the available services are discovered, the class instance invokes a callback to the instantiating object informing it that a list of discovered services is now available. ServerBrowserDelegate: This protocol requires any class instantiating a server object to implement the method updateserverlist that would serve as a callback for the instance of ServerBrowser class. Model Objects: This set contains a single class called MethodObject. Instances of this class are used by the client to call methods on the server. The client specifies the name of the method it intends to call, the class that implements the method and the arguments that need to be passed to the method. The arguments are added to an NSMutableArray. This object is then encoded by the framework and sent to the server where it is decoded and implemented. Server Classes: This set contains a single class called PublishService that can be instantiated and initialized using an object of a class whose services are intended to be published. It implements the ServerDelegate protocol from the Network Interface Classes set. Once instantiated, the application publishes the service using the method publishservicewithname:(nsstring*)andtype:(ns String*). The first parameter provides the name of the service that is used for the instantiation of AppConfig class and the second parameter is used to initialize the Server class by providing the service type and this is the same string that the client application would use to search for services. When a new client connects to the service, the ServerDelegate calls the method handlenewconnection:(connection*) of this class. The implementation of the method is such that the list of services (all the methods that can be called on the server) is returned to the client over the network packet to be used in whatever way the client may deem fit. The framework assumes that all the communication between the client and server will always be of the following pattern: a. the client calls a method on the server using the MethodObject b. the server implements the method and returns the response to the client Based on this assumption, when the server receives a network packet, it decodes the packet to create a

6 method object and then checks if the method name specified in the object can be implemented by the server. If the server can implement the method, an NSInvocation object is created. The NSInvocation object allows the programmer to specify the argument on which a method is to be called and the parameters that need to be passed as arguments. Once the NSInvocation object is set up, the invoke method of the object is called and the result is obtained. The framework checks for the returned result to be an instance of a class that implements the NSCoding protocol so that it may be encoded and sent back to the client. To enable the client to differentiate between a response and a list of methods (these are the only two things that a client may receive from the server), the server creates an NSDictionary object containing a single key-value pair that can be either be < methodlist, value> or < response, value>. Client Classes: This set contains of a single class called ClientConnection and a protocol called ClientConnectionDelegate. This protocol, ClientConnectionDelegate, specifies three methods that need to be implemented by the class in the client application that intends to act as the handler for all the callbacks of the ClientConnection object. These are: a. updateserviceslist:(nsarray *) - this method is called once all the available services on the network have been discovered. The returned array consists of a list of NSNetService objects b. methodsavailableonservice:(nsarray *) - this method is called when a client application creates a new connection to a server/service. The array received is the list of methods that are available on the server to be called. type of service (as described earlier) that it intends to search the name of the domain in which to search for that service and the object that is to act as a call back for the instantiated object. Once instantiated, the ClientConnection object in turn initializes and instantiates an object of the ServerBrowser class setting itself as the delegate for the created object. Once all the available services are discovered, the ServerBrowser object calls the updateserverlist. This method of the ClientConnection, in turn calls the updateserviceslist:(nsarray*) of its delegate. Once the client application chooses a service to connect to, it should call the connecttoservice:(nsnetservice*) method of the ClientConnection object with the service it intends to connect to as the parameter. In order to call a method on the server, the client application needs to call the callmethodonserverwithmethodobject:(methodo bject*) of the client object passing a MethodObject instance as the parameter. The ClientConnection then handles the encoding of the MethodObject instance and sending it over the network to the server. The ClientConnection object also handles the setting up of the service and upon receipt of a network packet, checks for the key ( methodlist or response ) and based on this, call one of the following methods on the delegate set, namely: methodsavailableonservice:(nsarray*) responseobjectreceivedfromserver:(id) The following figure (Fig. 4) describes the layout of the framework and how it may be used in an application. c. responseobjectreceivedfromserver: (id) - this method is called when the server returns a response from the method that the client requested to be called. When an object of the ClientConnection class is instantiated, the application needs to specify the

7 name of service. The framework allows only one service to be published by a given name. When the client application launches, the user may choose to view the published services. Once a list of available services is populated, the client is able to connect to any of the given services. Once connected to a given service, the client is able to view the items available on the menu of that service. The client may choose to select one of the items to place an order or return to the previous menu of the list of available services. Figure 4 Architecture of the framework IV. SAMPLE APPLICATION The framework would simplify the process of development of distributed applications and allow mobile application developers to create services, discover them dynamically and make dynamic procedure calls entirely on the mobile platform without having to rely on a desktop or a laptop allowing convenient usage to the end user. The application areas for such an implementation could find themselves useful in a number of domains like: Print services Restaurants publishing there menus as a service and users being able to view the menu items available and probably place orders from the device itself Stores of all kinds publishing the available deals as services and users being able to view the details of these deals via their device Directed Marketing To demonstrate the working of the framework, a sample application was developed that emulated the publishing of a restaurant s menu as a service. When the server application is launched, it asks the user to select a menu type that he would like to service. Once the menu is chosen, a service is published with the same name as the menu chosen by the user. The developer could also choose the When an order is placed, the server is informed of the order that was placed and it returns the client an expected time it would take for the processing of the order. V. CONCLUSION For the purposes of validation of the correct working of the framework, the sample application was developed and the following tasks were observed to be executing correctly: 1. Multiple services were published successfully by server applications on a given local network. 2. The published services were discoverable on client application if the local network allowed discovery of services and devices. 3. The client application was able to connect to one of the services at a time from the list of available services published on the network. 4. Upon connection, the client received a list of methods that could be called on the server. 5. The client was able to request the server to execute a method and receive a response object, if any. One of the limitations of the above framework is that the client is expected to have prior knowledge of the method signatures while making method calls to the server when passing parameters. The reason for this limitation to be imposed is because Objective-C dynamically links methods calls to the actual class methods at run time while checking if the parameters match to execute a given function call. It also does not allow for a method signature

8 to be serialized so that it can be passed to the client. Another limitation of the framework is that it is not able to discover available services, if the local network to which it is connected does not permit discovery of devices. This is an external limitation. A point to note when using this framework is that while building the application, the executable should be built using a linker flag -Objc - all_load. This needs to be done when a framework uses a category because if a pre-existing class with categories is extended, the linker does not know how to associate the object code of the core class implementation and the category implementation. This prevents the objects created in the application from responding to a method that is defined in the category. Since the developed framework implements the NSCoding protocol, it essentially extends the functionality by creating a category. The linker flag forces the linker to load every object file in the library that defines an Objective-C class or category. This leads to the creation of a larger executable file. Future work on the framework could include making the framework more robust. This would incorporate exploring ways to handle network delay issues and loss of data packets. Another aspect of the framework that could be looked into is that once the service discovery is started, the service browser keeps looking for services until it finds one. This could lead to the appearance of an application stalling. One way to resolve this issue would be to time the service browser out after a specific duration. Apple Documents. ntation/cocoa/conceptual/netservices/netservic es.pdf. Apple Game Center Documents. ation/networkinginternet/conceptual/gamekit_g uide/gamekit_guide.pdf. ICode Blog. static- libraries- for- ios/. Near Infinity /07/17/creating- and- using- static- libraries- for- iphone- using- xcode- 4.3.html. Wikipedia. call. VI. BIBLIOGRAPHY Apple Documents (Distributed Objects). entation/cocoa/conceptual/distrobjects/distrobj ects.html. Apple Documents (Dynamic Method Calls). entation/cocoa/conceptual/distrobjects/tasks/in vocations.html#//apple_ref/doc/uid/ CJBBACJH.