You are on page 1of 12

EX NO:1

STUDY OF WML AND J2ME SIMULATOR

AIM: To study about WML simulator and J2ME simulator for Mobile

WML Introduction WML (Wireless Markup Language) is a lightweight programming language used to generate applications that can be displayed in WAP enabled handset micro browser. It's based on XML and is basically a scaled down version of HTML, with some other tags thrown in. As data speeds for WAP devices are still generally rather slow, it's important that code be as lean as possible. Benefits of incorporating WAP/WML content Large and small companies engaged in ecommerce can take advantage of the technology now, without making a big investment, in a number of ways:

Keeping staff on the road up to date Letting clients know about special deals Providing tips and advice to your clients Announcing new products

Of course, this is only just scratching the surface. It's a good idea to gain a basic familiarity of WAP/WML issues as in the future, a huge percentage of ecommerce transactions will be carried out via WAP enabled handheld devices. Currently, WML is used most commonly for transmitting weather information, stock quotes and horoscopes. Gain a toehold into this rapidly growing market by implementing a few cell phone friendly pages on your site. Declaring A WML Document: When you are creating a WML document all you need is notepad or another text editor, just like for HTML. The first thing you should enter is: <?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"><wml> this tells the phone that it is interpreting a WML document and which WML standards it is using. Cards: Instead of having pages, WAP sites have cards. These are what is displayed on the screen at one time, just like a page. More than one card can be inserted in each WML document. To declare a card, insert the following: <card id="index" title="My WAP Site" newcontext="true">

This will make a card with the ID index (used for linking) and will display the text: My WAP Site at the top of the screen. Closing Tags Unlike with HTML, it is extremely important to close WML tags. If you do not, a page will certainly not work. You must close both the <card> and <wml> tags: </card> </wml> The <p> Tag Just like in HTML the <p> tag is used to show where a paragraph begins and ends. Unlike HTML though, all text on a WML page must be inside these tags. You are not allowed to nest these tags either. One important thing to remember about WML is that, unlike HTML where a page will still display even if there is bad code, a WAP phone will just reject a page if there is code it doesn't understand. As with HTML you use the tags as follows: <p> information </p> Aligning Text Aligning text in WML is nearly exactly the same as in HTML, except you can't use the center tag. All aligning must be done using the following <p> tags: Center: <p align="center"> Right: <p align="right"> The <br/> Tag In WML (as mentioned earlier) all tags must be closed. This causes problems when using old HTML tags (like <br>) which have no closing tag. To get around this, some tags have had a / put on the end e.g. <br/> This, like in HTML will make a line break. Text In WML there is actually no font tag (as you can only display text in the phone's default font in black). To show text all you need to do is put it in between the <p> and </p> tags. Here is an example of a full WML document: <?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml>

<card id="index" title="My WAP Site" newcontext="true"> <p align="center"> Welcome to my new WAP site. You can view this on your mobile phone anywhere in the world!<br/> It is amazing! </p> </card> </wml> Data Types WMLScript is a weakly typed language. This means that no type-checking is done at compile- or run-time and no variable types are explicitly declared. Internally, the following data types are supported: Boolean Integer Floating-point String Invalid The programmer does not need to specify the type of any variable; WMLScript will automatically attempt to convert between the different types as needed. One other point to note is that WMLScript is not objectoriented (such as Java or C++). Therefore, it is impossible to create your own user-defined data types programmatically. Operators WMLScript supports a variety of operators that support value assignment operations, arithmetic operations, logical operations, string operations, comparison operations, and array operations. For more information on the wide variety of WMLScript operators, see the WMLScript specification. Flow Control Statements The operators and expressions supported by WMLScript are virtually identical to those of the JavaScript programming language so we will not discuss them here. Java does support a number of control statements for handling branching within programs. These include the if-else, for loop, while loop, break, and continue statements. Functions Related WMLScript statements can be executed together as a unit known as a function. A function declaration has the following syntax: extern function identifier(FormatParameterList) Block ; The extern keyword is optional and is used to specify a function that can be called from outside the current compilation unit in which the function is defined. A sample WMLScript function declaration looks like this:

functionRunTime(distance, speed) { var time = distance / speed; return time; }; The above example simply takes two input variables, distance and speed, and uses them to calculate a time variable. The return keyword is then used to return a value. When calling a function included with one of the WMLScript standard libraries (see below), the library name must be included with the function call. For example, to call the String librarys length() function, use the following syntax: var a = String.length("1234567890"); J2ME Introduction : Mobile devices have a limited processing power, low heap and application size. In order to enable these devices with Java technology, SUN introduced Java 2 Micro Edition (J2ME). J2ME is a subset of J2SE with some APIs added specifically for the wireless devices. Just like for J2SE we have JVM (Java Virtual machine) to run the java applications; the J2ME applications run on KVM (kilo Bytes Virtual machine), which is basically a subset of JVM having limited resources, for eg, lacking support for floating point calculations. Every year a number of mobile devices are introduced in the market. These vary in screen size, processing speeds, operating systems, heap and application size limitations, etc. Hence, making a native application that can run on all these handsets is near to impossible. Heres where J2ME comes to fore!! Properly written J2ME applications can run on a variety of handsets, independent of OS, provided these handsets support J2ME. The most we may need to do is tweak the resources (art and sound) as per the phone specifications, while the same codebase may cover a vast number of devices. The process of making an application suitable for another handset is termed as porting. J2ME TECHNOLOGY J2ME is build upon the configurations, profiles and other optional packages. Configuration is the set of basic APIs on top of which the additional packages are built. Configuration tells you how big the KVM is and helps in the interaction with the device (via APIs). There are two types of versions available as of now: CLDC 1.0 CLDC 1.1 CLDC stands for Connected Limited Device Configuration. Profile gives you information about the mobile device and extends capabilities of configuration. It gives the control for the user interface, records storing etc. As of now there are two versions available MIDP 1.0 MIDP 2.0 MIDP stands for Mobile Information Device Profile. One major difference between the 1.0 and 2.0 is the advanced game APIs and the better key controls support 2.0 provides.

Optional Packages are the packages which Vendors and Manufacturers put on the specific devices to support additional features for ex Bluetooth, File System access, Camera APIs etc. Since most of the devices currently available in market support MIDP 1.0, it is always better to base your development on it, unless you have specific requirements to use higher version or if you dont plan to support the older devices. This also helps during the porting process. Tools and SDKs : JDK 1.4 or higher (available from Suns website) J2ME Wireless toolkit (available from Suns website) Emulators (Device Specific) Proguard or Retroguard (for obfuscation) Development IDE (generally we use Eclipse being open source and easy to use) Emulators can be downloaded from the vendors site. Sometimes it may happen that a specific emulator is not available, in that case you may need to work with any other emulator that provides you with similar specifications, esp the screen dimensions, heap and application size. Remember that you can only verify the user interface of your game by using emulators. The emulators do not reflect the actual game speed (frame per second, fps). So make sure to test your application on actual devices before you release for testing or in market. Retroguard or Proguard are for obfuscation purposes. They reduce your application size by removing the unwanted code, shorten the variable names and compress the graphics too if applicable. Making your first J2ME application : o Start the toolkit. o Select the New Project Tab. o Insert the Project Name and the Midlet Class Name. Click OK. o In the settings window, select the Midp 1.0 and Cldc 1.0 check box and select Ok. o Your New Project will get created. project Folder Structure Bin Src Classes Res Lib Bin: folder contains your jad, jar and the jar manifest file. JAD (Java Application Descriptor) file is your configuration file containing information like Midlet Class Name, Jar Size, Icon Info, Jar Size, Vendor etc. JAR (Java Archive) is the file that contains the application files and is deployed on the phone along with JAD file. What is the need of a JAD file?

It is actually used when you are hosting the application on Internet. When you download application via OTA, then firstly the JAD file is sent to the phone. Using the information in the JAD file, user is prompted with information about size of application, security certificates, company information etc. If the user approves then only the JAR file starts downloading. Src: Your java (source) files are kept inside this folder. Classes: When you compile source files using toolkit all your class files will be created inside the classes folder. Res: All the resources, graphics, sounds etc are kept in this folder. Lib: Any extra library (jar) files used by your application which may not exist on the phone, should be kept inside this folder. When you package the application by selecting the Create Package option from the toolkit, the files from classes, lib and res folders are packaged into a single jar file. Typical Game Application Class Structure : Following are the basic classes you require when you are developing a game: Midlet Canvas Data Engine Sprite Midlet As previously discussed, every J2ME application needs to have Midlet as an entry point for the application. Canvas Whatever you need to show to the user, you need a canvas class for that. Override the paint method to customize the application view. Data Many times you require constant data while developing an application. Make sure that all such data is kept in the Data java file as final static and you use these variables everywhere else inside the application. This will come handy when you need to change a value or when you are doing porting of the application. Engine This is the place where you keep your game logic. You may need to port your application to various devices and sometimes you may need to use device manufacturer / device specific APIs too, eg. FullCanvas class from Nokia. Hence, it is better to separate out the game logic from the view and other helper classes. This way you wont need to change the game logic when you port to other devices. Sprite Since most of the games require animation of characters, so you need a sprite class for that. A sprite class has all the information required to show the various stages of a character at different points in time / screen.

RESULT: Thus the study of WML Simulator and J2ME Simulator was completed

EX NO:10

STUDY OF GloMoSim MOBILE SIMULATOR

AIM: To study about GloMOSim simulator

GloMoSim Introduction: Global Mobile Information System Simulator (GloMoSim) is a scalable simulation environment for large wireless and wireline communication networks. GloMoSim uses a parallel discreteevent simulation capability provided by Parsec. GloMoSim simulates networks with up to thousand nodes linked by a heterogeneous communications capability that includes multicast, asymmetric communications using direct satellite broadcasts, multi-hop wireless communications using ad-hoc networking, and traditional Internet protocols. The following table lists the GloMoSim models currently available at each of the major layers:

The node aggregation technique is introduced into GloMoSim to give signi cant bene ts to the simulation performance. Initializing each node as a separate entity inherently limits the the scalability because the memory requirements increase dramatically for a model with large number of nodes. With node aggregation, a single entity can simulate several network nodes in the system. Node aggregation technique implies that the number of nodes in the system can be increased while maintaining the same number of entities in the simulation. In GloMoSim, each entity represents a geographical area of the simulation. Hence the network nodes which a particular entity represents are determined by the physical position of the nodes. The multitude of proposed solutions at each protocol layer for wireless, wireline, and satellite networks has led to an explosion in possible design choices for networks such as these. The size of these networks makes experimentation and measurement prior to deployment impossible, yet the risks of deploying these new technologies in critical situations require assurance that they will work. Detailed, high fidelity simulation of the communication infrastructure can provide invaluable insights. Under current funding from DARPA, we are developing a scalable simulation facility whose objective is to simulate networks with upto hundred thousand nodes linked by a heterogeneous communications capability that includes multicast, asymmetric communications using direct satellite broadcasts, multi-hop wireless communications using ad hoc networking, and traditional Internet protocols.

Use of GloMoSim Simulator After successfully installing GloMoSim, a simulation can be started by executing the following command in the BIN subdirectory. ./glomosim < inputfile > The <input le> contains the con guration parameters for the simulation (an example of such le is CONFIG.IN). A le called GLOMO.STAT is produced at the end of the simulation and contains all the statistics generated. Coding in GloMoSim: In many cases we would like to modify the source les or create new les in order to add or obtain new functionality. New protocols can be written and interfaced with GloMoSim at any layer of the OSI model. In general, the coding style of the source le should be followed when modifying the code. Some general advices are the following: Use long, descriptive and easily read procedure and variable names. Try not to use abbreviations or encodings. Use real words in variable names like Header not Hdr. Macro constants should be upper case letters with underlines. Identi ers for functions performing an action should contain a verb, for example, InitializeValues, CreateQueue etc. Identi ers for boolean functions or variables should have Is or Has in their name. For example, IsOccupied. Do not use more than 80 column width as wrapped lines are very dicult to read. Block comments are on separate lines from code. They are indented to the same level as the code they are in. The reason that GloMoSim uses a main function is because it is needed to collect the statistics into a single le and close the le neatly. Therefore a function that runs after all the glomo entities have been nalized is required. An example of how to use parsec main() function to print a message is represented by the following hola.pc program: #include <stdio.h> int main(int argc, char **argv){ parsec_main(argc,argv); printf("Simulation Ended\n\n"); } entity driver (int argc, char **argv) { int i; printf("HELLO WORLD \n\n"); }

The entity driver is called by the parsec main() function, prints the message \HELLO WORLD", the simulation ends and the message \Simulation Ended is printed". The commands to compile the program are shown as follows. The clock option specify clocktype to use (unsigned by default), while the user main option rename main() to parsec main() for a user-de ned main(). > pcc -g -O3 -clock longlong -lm -c hola.pc > pcc -g -O3 -clock longlong -user_main hola.o -lm -o hola >./hola HELLO WORLD Execution time : 0.0007 sec Number of events (including timeouts) processed : 0 Number of messages processed : 0 Number of context switches occurred : 6 Number of Local NULL messages sent : 0 Number of Remote NULL messages sent : 0 Total Number of NULL messages sent : 0 Simulation Ended > Function RoutingAodvSetTimer set the timer by sending a message to the corresponding network layer. The last argument of this function is the delay from the current simulation time. NODE TRAVERSAL TIME is de ned by default to 40ms in the /glomosim/network/aodv.h le. Function RoutingAodvSetTimer is de ned as follows: void RoutingAodvSetTimer( GlomoNode *node, long eventType, NODE_ADDR destAddr, clocktype delay) { Message *newMsg; NODE_ADDR *info; newMsg = GLOMO_MsgAlloc(node, GLOMO_NETWORK_LAYER, ROUTING_PROTOCOL_AODV, eventType); GLOMO_MsgInfoAlloc(node, newMsg, sizeof(NODE_ADDR)); info = (NODE_ADDR *) GLOMO_MsgReturnInfo(newMsg); *info = destAddr; GLOMO_MsgSend(node, newMsg, delay);

Scalability of GloMoSim: The node aggregation technique gives significant benefits to the simulation performance. As each entity needs to examine packet receptions only for the nodes located in the region it is simulating, using many partitions reduce the total search space for packet delivery. In for instance, if a packet sent by a node

located in Partition (0, 0) cannot reach the border of the partition, no message needs to be sent to the other partitions. Therefore, the other partitions do not have to examine the reception of the packet, which reduce the region to be examined for the packet by a factor of four compared to using single partition. shows the impact of multiple partitions for the models with 2500 and 5000 wireless nodes. Both simulation models consist of wireless nodes running CSMA at the MAC layer, each of which is randomly placed in 2000 x 2000m free space region. As seen in the executions for both models become faster as the number of partitions increases. The effect of multiple partitions is larger for the model with 5000 nodes as the reduction in the execution time is related to the number of wireless nodes to be examined for each radio transmission. Simulation of a Replicated File System: Optimistically replicated file systems have been suggested as an effective method to provide users access to shared files, even when they are temporarily disconnected [13]. Such file systems work on the following principles: replicas, or copies, of a file are stored on multiple computers. Using optimistic replication, a users read or write operations are directed to the local replica. This can lead to file consistency problems when concurrent updates are made to multiple replicas of a given file. A process called reconciliation, which involves two replicas on separate computers, addresses such inconsistencies. During reconciliation, replicas are compared and updates are propagated between the two computers. When a server generates a reconciliation request it will also specify the target server based on the reconciliation topology, which is distinct from the physical topology in which the servers may be organized. Examples of reconciliation topology include tree, ring, and star topologies. The design of a scalable replicated file system involves a number of considerations. At the fundamental level, it is necessary to identify the costs paid due to greater availability and reliability; effects of file access patterns on performance; impact of data exchange method, data propagation topology, data synchronization interval, and lastly how all these metrics change as the system is scaled up to hundreds of replicas. Some of the common metrics that have been proposed to evaluate the quality of service offered by a replicated file system include the stale read and write rate as well as cost measurements of CPU and network bandwidth usage. Conclusion: Detailed, high fidelity models of large networks represent a significant challenge for the networking community. As the military moves towards deploying a digital communication infrastructure, it is imperative that the performance of the communication devices be thoroughly studied prior to deployment to understand the limits of the network and its ability to handle diverse traffic under stringent operating conditions. This paper presented a simulation library called GloMoSim whose goal is to support accurate performance prediction of large-scale network models using parallel execution on a diverse set of parallel computers. The library has already been used to simulate networks with thousands of wireless nodes and provides a rich set of models for both existing and novel protocols at multiple layers of the protocol stack. It has been used to undertake numerous performance studies among alternative protocols both at UCLA and other organizations.

RESULT: Thus the study of GloMoSim Simulator was completed

You might also like