Interconection Protocols Term Project “ Remote Control of a PC with Mobile Phone ”

1. Interconection ProtocolsTerm Project“Remote Control of a PC with Mobile Phone” 514051003 Gökçe ATILGAN 514051007 Meriç YÜCEL

2. Definition of Project • Remote control of a PC from a mobille phone • Orders are given either by voice or pressing a related button on mobile phone • Communication is two dimensional • Hand Shaking

3. Software Used • Microsoft Visual C++ 6.0 • Netbeans 4.1 – Mobile Application • J2sdk-1.4 • Netbeans_mobility-4.1 • Ns60_jme_sdk_v2.1

4. Mobile flowchart

8. Mobile Media API The Mobile Media API (JSR 135) is an optional API targeted at J2ME CLDC based devices that defines a framework to support • Playback and recording of audio and videos • Plus photo capture from an onboard camera • Volume Control • Tone generation

9. The Architecture of the Mobile Media API

10. createPlayer() • Players are created using the createPlayer (...) factory method of thejavax.microedition.media.Manager Class. The createPlayer (...) method has 3 signatures. These are • Public static Player createPlayer(String locator) • Public static Player createPlayer(lnputStream stream, String type) • Public static Player createPlayer(DataSource source)

11. createPlayer() cont’2 • First signature is used in this project. • player = Manager.createPlayer( "capture://audio?rate=8000&bits=16"); • Create a player from an input locator • Parameters • Locator-A locator string in URI syntax that describes the meda content • Returns • A new player

12. Player • Player controls the rendering of time based media data. It provides the methods to manage the Player's life cycle, controls the playback progress, obtains the presentation components, controls and provides the means to synchronize with other Players.

13. Player Life Cycle

14. Player Life Cycle Cont’2 • A Player has five states: UNREALIZED, REALIZED, PREFETCHED, STARTED, CLOSED. • The purpose of these life-cycle states is to provide programmatic control over potentially time-consuming operations. For example, when a Player is first constructed, it's in the UNREALIZED state. Transitioned from UNREALIZED to REALIZED, the Player performs the communication necessary to locate all of the resources it needs to function (such as communicating with a server or a file system). The realize method allows an application to initiate this potentially time-consuming process at an appropriate time.

15. Player Life Cycle Cont’3 • Typically, a Player moves from the UNREALIZED state to the REALIZED state, then to the PREFETCHED state, and finally on to the STARTED state. • A Player stops when it reaches the end of media; when its stop time is reached; or when the stop method is invoked. When that happens, the Player moves from the STARTED state back to the PREFETCHED state. It is then ready to repeat the cycle. • To use a Player, programmer must set up parameters to manage its movement through these life-cycle states and then move it through the states using the Player's state transition methods.

16. UNREALIZED State • A Player starts in the UNREALIZED state. An unrealized Player does not have enough information to acquire all the resources it needs to function. The following methods must not be used when the Player is in the UNREALIZED state. • getContentType • setTimeBase • getTimeBase • setMediaTime • getControls • getControl

17. REALIZED State • A Player is in the REALIZED state when it has obtained the information required to acquire the media resources. Realizing a Player can be a resource and time consuming process. The Player may have to communicate with a server, read a file, or interact with a set of objects. • Although a realized Player does not have to acquire any resources, it is likely to have acquired all of the resources it needs except those that imply exclusive use of a scarce system resource, such as an audio device. • Normally, a Player moves from the UNREALIZED state to the REALIZED state. After realize has been invoked on a Player, the only way it can return to the UNREALIZED state is if deallocate is invoked before realize is completed. Once a Player reaches the REALIZED state, it never returns to the UNREALIZED state. It remains in one of four states: REALIZED, PREFETCHED, STARTED or CLOSED.

18. PREFETCHED State • Once realized, a Player may still need to perform a number of time-consuming tasks before it is ready to be started. For example, it may need to acquire scarce or exclusive resources, fill buffers with media data, or perform other start-up processing. Calling prefetch on the Player carries out these tasks. • Once a Player is in the PREFETCHED state, it may be started. Prefetching reduces the startup latency of a Player to the minimum possible value. • When a started Player stops, it returns to the PREFETCHED state.

19. STARTED State • Once prefetched, a Player can enter the STARTED state by calling the start method. A STARTED Player  means the Player is running and processing data. A Player returns to the PREFETCHED state when it stops, because the stop method was invoked, it has reached the end of the media, or its stop time. • When the Player moves from the PREFETCHED to the STARTED state, it posts a STARTED event. When it moves from the STARTED state to the PREFETCHED state, it posts a STOPPED, END_OF_MEDIA or STOPPED_AT_TIME event depending on the reason it stopped. • The following methods must not be used when the Player is in the STARTED state: • setTimeBase • setLoopCount

20. CLOSED state • Calling close on the Player puts it in the CLOSED state. In the CLOSED state, the Player has released most of its resources and must not be used again.

21. realize() • Constructs portions of the Player without acquiring the scarce and exclusive resources. This may include examining media data and may take some time to complete. • When realize completes successfully, the Player is in the REALIZED state. • If realize is called when the Player is in the REALIZED, PREFETCHTED or STARTED state, the request will be ignored.

22. start() • Starts the Player as soon as possible. If the Player was previously stopped by calling stop or reaching a preset stop time, it will resume playback from where it was previously stopped. If the Player has reached the end of media, calling start will automatically start the playback from the start of the media. • When start returns successfully, the Player must have been started and a STARTED event will be delivered to the registered PlayerListeners. However, the Player is not guaranteed to be in the STARTED state. The Player may have already stopped (in the PREFETCHED state) because the media has 0 or a very short duration. • If start is called when the Player is in the UNREALIZED or REALIZED state, it will implicitly call prefetch. • If start is called when the Player is in the STARTED state, the request will be ignored.

23. close() • Close the Player and release its resources. When the method returns, the Player is in the CLOSED state and can no longer be used. • A CLOSED event will be delivered to the registered PlayerListeners. • If close is called on a closed Player the request is ignored.

24. RecordControl • RecordControl controls the recording of media from a Player. RecordControl records what's currently being played by the Player.

25. startRecord() • Start recording the media. • If the Player is already started, startRecord will immediately start the recording. If the Player is not already started, startRecord will not record any media. It will put the recording in a "standby" mode. As soon as the Player is started, the recording will start right away. • If startRecord is called when the recording has already started, it will be ignored. • When startRecord returns, the recording has started and a RECORD_STARTED event will be delivered through the PlayerListener. • If an error occurs while recording is in progress, RECORD_ERROR event will be delivered via the PlayerListener.

26. commit() • Complete the current recording. • If the recording is in progress, commit will implicitly call stopRecord. • To record again after commit has been called, setRecordLocation or setRecordStream must be called.

27. stopRecord() • Stop recording the media. stopRecord will not automatically stop the Player. It only stops the recording. • Stopping the Player does not imply a stopRecord. Rather, the recording will be put into a "standby" mode. Once the Player is re-started, the recording will resume automatically. • After stopRecord, startRecord can be called to resume the recording. • If stopRecord is called when the recording has already stopped, it will be ignored. • When stopRecord returns, the recording has stopped and a RECORD_STOPPED event will be delivered through the PlayerListener.

28. setRecordStream(java.io.OutputStream stream) • Set the output stream where the data will be recorded. • Parameters: • stream - The output stream where the data will be recorded.

29. reset() • Erase the current recording. If the recording is in progress, reset will implicitly call stopRecord. • Calling reset after commit will have no effect on the current recording. • If the Player that is associated with this RecordControl is closed, reset will be called implicitly.

30. Controllable • Controllable provides an interface for obtaining the Controls from an object like a Player. It provides methods to query all the supported Controls and to obtain a particular Control based on its class name.

31. getControl • public ControlgetControl(java.lang.String controlType) • Obtain the object that implements the specified Control interface. If the specified Control interface is not supported then null is returned. • If the Controllable supports multiple objects that implement the same specified Control interface, only one of them will be returned. To obtain all the Control's of that type, use the getControls method and check the list for the requested type. • Parameters: • controlType - the class name of the Control. The class name should be given either as the fully-qualified name of the class; or if the package of the class is not given, the package javax.microedition.media.control is assumed. • Returns: • the object that implements the control, or null.

32. SocketConnection • This interface defines the socket stream connection. • A socket is accessed using a generic connection string with an explicit host and port number. The host may be specified as a fully qualified host name or IPv4 number. e.g. socket://meric:4683 defines a target socket on the meric system at port 4683.

33. Connector.open() • The URI must conform to the BNF syntax specified below. If the URI does not conform to this syntax, an IllegalArgumentException is thrown. • SocketConnection sc = (SocketConnection) Connector.open("socket://meric:4683");

34. BNF syntax

35. openInputStream • public java.io.InputStream openInputStream() • Open and return an input stream for a connection. • Returns: • An input stream

36. openDataInputStream • public java.io.DataInputStream openDataInputStream() • Open and return a data input stream for a connection. • Returns: • An input stream

37. openOutputStream • public java.io.OutputStream openOutputStream() • Open and return an output stream for a connection. • Returns: • An output stream

38. openDataOutputStream • public java.io.DataOutputStream openDataOutputStream() • Open and return a data output stream for a connection. • Returns: • An output stream

39. Available() • data_input_stream.available() • Returns the number of bytes that can be read from this input stream without blocking. • This method simply performs • in.available() • And returns the result

40. Read(byte[ ] b ) • data_input_stream.read(buf) • Reads some number of bytes from the input stream and stores them into the buffer array b. The number of bytes actually read is returned as an integer. This methods blocks until input data is available, end of file is detected, or an exception is thrown.

41. Ready() • input_stream_reader.ready() • Tell whether this stream is ready to be read. • Returns • True if the next read() is guaranteed not to block for input, false otherwise. Returning false does not guarantee that the next read will block.

42. Write(byte [ ] b,int off,int len ) • data_output_stream.write(deneme, 0, deneme.length); • Writes len bytes from array b, in order, to the output stream. If b is null, a NullPointerException is thrown. If off is negative, or len is negative, or off+len is greater than the length of array b, then an IndexOutOfBoundException is thrown. If len is zero, then no bytes are written. Otherwise,the byte b[off] is written first, then b[off+1], and so on; the last byte written is b[off+len-1].

43. flush () • data_output_stream.flush() • Flushes this data output stream. This forces any buffered output bytes to be written out to the stream. • The flush method of DataOutputStream calls the flush method of its underlying output stream.

44. Socket Interface • socket interface is an API that allows communications between hosts or between processes on one computer, using the concept of a socket. • It is able to work with many different I/O devices and drivers, although support for this is dependent on the operating system implementation. • This interface implementation is implicit for TCP/IP, and it is therefore one of the fundamental technologies underlying the internet.

45. TCP • TCP provides the concept of a connection. A TCP socket is created by calling the socket() function with the parameters AF_INET and SOCK_STREAM, respectively.

46. Simple TCP Server Steps • Creating a TCP socket, with a call to socket(). • Binding the socket to the listen port, with a call to bind(). Before calling bind(), a sockaddr_in structure must be declared and cleared (with bzero()), and the sin_family (AF_INET) and sin_port (the listening port, in network byte order) fields of it must be filled. Converting a short int to network byte order can be done by calling the function htons() (host to network short).

47. Simple TCP Server Steps Cnt’2 • Preparing the socket to listen for connections (making it a listening socket), with a call to listen(). • Accepting incoming connections, via a call to accept(). This blocks until an incoming connection is received, and then returns a socket descriptor for the accepted connection. The initial descriptor remains a listening descriptor, and accept() can be called again at any time with this socket, until it is closed.

48. Simple TCP Server Steps Cnt’3 • Communicating with the remote host, which can be done through read() and write(). • Eventually closing each socket that was opened, once it is no longer needed, using close(). It's worth noting that if there were any calls to fork(), each process must close the sockets it knew about (the kernel keeps track of how many processes have a descriptor open), and two processes should not use the same socket at once.

49. socket() • sd = socket(PF_INET, SOCK_STREAM, ptrp->p_proto) • socket() creates an endpoint for communication and returns a descriptor. Socket takes three arguments: • domain, which specifies the address family of the socket that is created (AF_INET, for example). • type, which is one of SOCK_STREAM (TCP), SOCK_DGRAM (UDP), or SOCK_RAW (RAW). • protocol, which is usually set to 0 to represent the default protocol for the specified domain and type. • The function returns -1 if an error occurred. Otherwise, it returns an integer representing the newly-assigned descriptor.

50. bind() • bind(sd, (struct sockaddr *)&sad, sizeof(sad)) • bind() assigns a socket an address. When a socket is created using socket(), it is given an address family, but not assigned an address. Before a socket may accept incoming connections, it must be bound. bind() takes three arguments: • sockfd, a descriptor representing the socket to perform the bind on • my_addr, a pointer to a sockaddr structure representing the address to bind to. • addrlen, a socklen_t field representing the length of the sockaddr structure. • It returns 0 on success and -1 if an error occurs.