Interconection ProtocolsTerm Project

“Remote Control of a PC with Mobile

Phone”

514051003 Gökçe ATILGAN

514051007 Meriç YÜCEL

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

Software Used

• Microsoft Visual C++ 6.0

• Netbeans 4.1 – Mobile Application

• J2sdk-1.4

• Netbeans_mobility-4.1

• Ns60_jme_sdk_v2.1

Mobile flowchart

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

The Architecture of the Mobile Media API

createPlayer()

• Players are created using the createPlayer (...) factory method of the javax.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)

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

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.

Player Life Cycle

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.

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.

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

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.

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.

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

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.

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.

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.

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.

RecordControl

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

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.

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.

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.

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.

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.

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.

getControl

• public Control getControl(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.

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.

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");

BNF syntax

<socket_connection_string> ::= "socket://"<hostport>

<hostport> ::= host ":" port

<host> ::= host name or IP address

<port> ::= numeric port number

openInputStream

• public java.io.InputStream openInputStream() – Open and return an input stream for a

connection. – Returns:

• An input stream

openDataInputStream

• public java.io.DataInputStream openDataInputStream() – Open and return a data input stream for a

connection. – Returns:

• An input stream

openOutputStream

• public java.io.OutputStream openOutputStream() – Open and return an output stream for a

connection. – Returns:

• An output stream

openDataOutputStream

• public java.io.DataOutputStream openDataOutputStream() – Open and return a data output stream for a

connection. – Returns:

• An output stream

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

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.

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.

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].

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.

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.

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.

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).

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.

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.

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.

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.

listen()

• listen(sd, QLEN)• listen() prepares a bound socket to accept incoming

connections. This function is only applicable to the SOCK_STREAM and SOCK_SEQPACKET socket types. It takes two arguments:– sockfd, a valid socket descriptor. – backlog, an integer representing the number of pending

connections that can be queued up at any one time. The operating system usually places a cap on this value.

• Once a connection is accepted, it is dequeued. On success, 0 is returned. If an error occurs, -1 is returned.

accept()

• sd2=accept(sd, (struct sockaddr *)&cad, &alen)• Programmers use accept() to accept a connection

request from a remote host. Its arguments are:– sockfd, the descriptor of the listening socket to accept the

connection from. – cliaddr, a pointer to the sockaddr structure that accept() should

put the client's address information into. – addrlen, a pointer to the socklen_t integer that will indicate to

accept() how large the sockaddr structure pointed to by cliaddr is. When accept() returns, the socklen_t integer then indicates how many bytes of the cliaddr structure were actually used.

• The function returns a socket corresponding to the accepted connection, or -1 if an error occurs.

send()

• int send(int sd, const void *msg, int len, int flags)

• sd is the socket descriptor to send data to, msg is a pointer to the data that want to send, and len is the length of that data in bytes.

• send() returns the number of bytes actually sent out–this might be less than the number wanted to send!

recv()

• int recv(int sd, void *buf, int len, unsigned int flags)

• sockfd is the socket descriptor to read from, buf is the buffer to read the information into, len is the maximum length of the buffer.

• recv() returns the number of bytes actually read into the buffer, or -1 on error

• recv() can return 0. This can mean the remote side has closed the connection

FFT Algorithm

• Cooley- Turkey algorithm is used– Recursive algorithm– 2^n samples

• İf not algorithm makes itself 2^n samples by adding zeros to the related file

Signal Comparison

• Related peek samples already taken for “shutdown”, “reset” , “winword”, “internet explorer” .

• Time samples came from mobile phone transformed to frequency domain with FFT algorithm.

• 5 biggest peaks are chosen to compare signals• Controls the every 5 peaks’ difference and

searches for smallest one.• And related order is sent to mobile phone.• Flow Chart of server side is shown in next page