Internet Based Electronic Booking System for a Building S Laundry Room
Total Page：16
File Type：pdf, Size：1020Kb
Web Based Booking System
PREFACE
I would like to thank the great support offered by the personnel from ISBIT AB. Specially to Christian Andersson for his supervision during the development of this project. I also want to thank Kristian Sandström from Mälardalens Högskola for the support offered in the correction and clarification of concepts in this report.
ABSTRACT
Today exists the possibility for real estate owners of using electronic booking units to control the building’s laundry room. These units substitute today’s manual booking systems and they also can control peoples the access to the laundry room shared by the residents. This means, for example, that the access to a laundry room, under a certain time, is restricted to the user that has reserved that time. As Internet is becoming more available and convenient and with the fast development of present communication systems, like broadband and the WAN, web based laundry booking will be of higher interest for both real estate owners and their residents. The objective of this degree project was to develop a web based booking system that enables the users of laundry rooms to perform all the tasks that they usually can do through the electronic booking unit, but now via Internet. The system consists of a hardware device, the electronic booking unit, that communicates with an embedded PC/104 compatible system with P266 MHz processor, 100 Mbit Ethernet network, RS232 serial communication, 32 MB RAM memory and a 16MB Flash Disc. The operating system is a modified and reduced Linux distribution, which contains an Apache server. This report requires of the reader to have at least a couple of years of studies in computer science. CONTENTS
INTRODUCTION...... 1 Background...... 1 Description of the present system...... 1 The hardware...... 1 The Software...... 1 Advantages and disadvantages...... 2 Purpose...... 2 Demarcations...... 2 The structure of the report...... 2 DESCRIPTION OF THE TASK...... 3 Problem...... 3 Goal...... 3 THEORY...... 4 Socket...... 4 System V Inter Process Communication (IPC)...... 5 Semaphores...... 7 Shared Memory...... 7 Messages Queues...... 8 CGI...... 10 Serial Communication...... 11 ANALYSIS...... 12 Requirements...... 12 Customer related requirements...... 12 System related requirements...... 12 The problem and the possible solutions...... 13 DESIGN...... 16 Client Process...... 16 Class description...... 18 Server Process...... 18 Class Description...... 21 IMPLEMENTATION...... 22 Client Process...... 22 Main method...... 22 Execute method...... 22 Server Process...... 23 Main method...... 23 Start method...... 23 Execute method...... 23 CONCLUSIONS...... 26
REFERENCES...... 26
II LIST OF TABLES
Table 1: sockets system calls...... 5 Table 2 Summary of System V IPC system calls...... 5 Table 3 Summary of the access permissions...... 6
LIST OF FIGURES
Figure 1: UML-diagram for the client process...... 17 Figure 2: UML-diagram for the server process...... 20 Figure 3: UML-sequence diagram for the reserve cancel command...... 24 Figure 4: ULM-sequence diagram for the set time command...... 25
III INT RODUCT ION
BACKGROUND
ISBIT AB is a company in the area of advance software engineering within Industrial IT. The company was established in 1998, and the main office is in Västerås. At the present there are 25 consults working in different projects. The biggest customer in Västerås is ABB, the leader company within Industrial IT.
ADC Systems was established in 1996 with the idea of producing smart card readers at a component level. It is a company lied in Gothenburg. During the last 5 years this company has developed complete products and systems for contactless smart cards, as PCB readers for OEM business as well as capsulated products in areas as public transportation, access control and industrial areas.
One of the offered products is an electronic laundry-booking unit. Its objective is to give real estate owners a tool to control people access to the laundry room shared by the residents. The business developers at ISBIT saw the possibility of adding more value to this unit through development a web based system to access it.
DESCRIPTION OF THE PRESENT SYSTEM
THE HARDWARE
The hardware consists of an embedded PC/104 compatible system with P266 MHz processor, 100 Mbit Ethernet network serial communication, the electronic booking system. A strongly diminished Linux-distribution that contains an apache web server. The storage media is a 16MB flash card memory that supports multi-level power down capability for power saving benefits. Comply with PC Card (PCMCIA) ATA standards, up to 1 million write/erase cycles and unlimited read cycles
THE SOFTWARE
At the present time, there is a well functioning version of the system in use. It is composed of three processes: a client process, a server process and a process that deal with communication with the booking unit via serial communication, called rs232. Every process is implemented in ANSI C and includes a number of functions that take care of the incoming data from the other process in the system.
A transaction may be started in two ways: through the booking unit, or by a browser client. Any of these ways exclude the possibility of parallel treatment of data, which means that if a browser client starts a transaction, it will reach at sometime the server process. The server further will send the request to the serial component, and waits for response. When the rs232 process receives the data sends it bit for bit to the booking unit. It’s at this time that the booking unit will be blocked, showing this
1 by sending a message to the unit’s user display. When the booking unit is ready with this task, it sends a response to the serial component, and becomes ready to receive the next request. The serial component rs232 receives the message, decodes it and sends back to server process information about the transaction. The server process updates the database and sends the actual state of the system to the client. Finally, the client process makes a html page, sends it to the browser, and finishes. This system uses socket for communication between the different processes, and serial communication between the server process and the electronic laundry- booking unit.
ADVANTAGES AND DISADVANTAGES
This form of programming makes difficult future development of the system, since other programmers, who can be involved in this project, will have to review great part of the code to be able to understand how the program is constructed. In addition, which seemed to be an advantage, the unrestricted access to the data, becomes here in a problem because it makes difficult to new programmers knowing how and where data is acceded. Other of the problems that is evident here is the difficulty to test the different parts of system independently. This can result, in the worse case, that a programmer may be forced to rewrite one or more parts of the code.
PURPOSE
The purpose of this report is to present an alternative solution to the problem, based on the object-oriented design that satisfies the requirements of the system, and that facilitates the development of this one.
DEMARCATIONS
Since one of the limitations in this project is the time available for the development, the developed prototype in this degree project will provide the users with a some facilities, such as look for a week in the database, reserve/cancel a wash time and setting the system and the unit time.
THE STRUCTURE OF THE REPORT
DESCRIPTION OF THE TASK: Presents a description of the problem and what are the goals for this project. THEORY: Reviews the different theories that this project rests on. ANALYSIS: Presents the requirements of the system and suggests possible solutions DESIGN: This section describes what classes constitute every process in the system and how they are related to each other. We use UML diagrams to show these relations. IMPLEMENTATION: This section will give a description of the different messages along a transaction. CONCLUSION: Presents the conclusions of this degree project and propound further development. REFERENCES.
2 BIBLIOGRAPHY
3 D ESCRIPT ION OF T HE TASK
PROBLEM
The building of a booking system raises a chain of problems to solve in order to produce a stable and robust system:
Guarantee the transference of data from a Internet client to the system’s database Updating of data in the electronic laundry-booking unit Guaranteeing of the atomicity of the transactions. In this case, atomic transaction means to receive from the unit a well-known answer to a certain request that has a relation with the question Ward again system crash or halt. Guarantee a multi-user system. All the transactions will be synchronous, that is to say, the system will not treat more than a transaction simultaneously. Sending right answer to right client
GOAL
The purpose of this project is to develop a system that allows the access and the administration of the electronic laundry-booking unit via the Internet. This means that the system users should be able to execute the same tasks via the Internet as at the electronic laundry-booking unit.
Furthermore, the system should be design in such a way that enables increasing development of the system, in order to introduce new features, without to redesign it.
4 T HE ORY
SOCKET
Sockets are a generalized networking capability introduced by BSD (Berkeley Software Distribution), and it constitutes an API to the communication protocols (TCP, UDP, IP). A socket is defined as an endpoint of communication to which a name can be bound. It has a type and one or more associated processes. They provide point-to-point, two-way communication between two different processes on the same or different machines. Sockets exist in communication domains (that is, abstractions that provide an addressing structure and a set of protocols), and connect only with sockets in the same domain.
Like other forms of inter-process communication, sockets can be used to communicate between processes on a single system. For this purpose, in the UNIX domain (or AF_UNIX) a socket is given a path name within the file system name space. A file system node is created for the socket and other processes may then refer to the socket by giving the proper pathname. UNIX domain names, therefore, allow communication between any two processes that work in the same file system. They can also be used to communicate between processes on different systems. The socket address space between connected systems is called the Internet domain, and uses the TCP/IP Internet protocol. Addresses in the Internet domain consist of a machine network address and an identifying number, called a port.
Basically, a socket behaves like a low-level file descriptor. It uses the system calls read, write and close in the same way that files do. However, sockets differ from file descriptors in the way that they are created, and through a variety of special operations to control them. These operations are necessary because of the additional complexity in establishing network connections when compared with normal disk access. For communication with socket, the operating system provides several system calls, which constitutes the socket’s interface:
Socket Creates an endpoint for communication and returns a descriptor Bind Assigns a name ton an unnamed socket connect Initiates a connection on a socket Listen Used by a connection-oriented server to indicate that it is ready to receive connections accept Accepts a connection on a socket. Accept takes the first connection request on the queue and creates another socket with the same properties as the incoming socket descriptor send, sendto Sends a message from a socket recv, Receives a message from a socket recvfrom Close Closes a file descriptor. In this case a socket descriptor
5 gethostbynam This call returns the host information from the local DNS e using the hostname Table 1: sockets system calls
Another aspect that increments the complexity of the use of socket, with inter process communication, is the roles of the processes. One must actuate as a server, and the other as a client. These roles, concerning communication, are not symmetric and cannot be reversed without some attempt.
There are two way to make a connection using sockets: connection-oriented or connection less. Connection-oriented service works like a telephone service. When host X desires to communicate with host Y, X makes a request from the network to establish a connection to Y. Y has the option to accept or discard this connection. If Y agrees to the connection, the network system reserves a data path between X and Y and tells them that they can now communicate. X and Y communicate as long as they desire, and each can send information anytime it wants. They are also free to send any amount of data any time they want, because there is lower layer software that transparently splits the data into packets for transmission. Both nodes can request that the connection be closed at any time.
For a client-server communication using a connectionless protocol, the system calls are not the same. On the one hand, the client does not establish a connection with the server, but just sends a datagram to the server using the sendto system call (a datagram is datagram a message that containing not only data but also the source and the destination address). On the other hand, the server does not need to accept a connection from a client. It only has to use the recvfrom system call to wait until data arrives from some client. This system call returns the network address of the client process.
SYSTEM V INTER PROCESS COMMUNICATION (IPC)
The IPC services provide a clean, consistent solution to passing data between processes on the same machine. There are three types of IPC facilities: Semaphores, shared memory and messages queues. They share many similarities in the system calls that access them, and in the information that the kernel maintains on them. A summary of their system calls is shown in the table bellow.
Facility Message queue Semaphore Shared Memory System call to create or msgget Semget shmget open System call to control msgctl Semctl shmctl operations System call for IPC msgsnd, shmat, operations msgrcv shmdt Table 2 Summary of System V IPC system calls
The UNIX system V IPC enables us to perform the following tasks:
6 Create and handle semaphores. This includes the capability to read, set, and reset semaphore values. Send messages from one process to another by a message queue. Processes can add messages to a queue, check the length of a queue, and remove messages from a queue. Create and handle shared memory. This includes the capability to read from and write into areas of shared memory.
For each resource the system uses a common structure of type struct ipc_perm to store information needed in determining permissions to perform an ipc operation. The ipc_perm structure, defined by the
struct ipc_perm{ ushort uid; /* owner’s user id*/ ushort gid; /* owner’s group id */ ushort cuid; /* creator’s user id*/ ushort cgid; /* creator’s group id*/ ushort mode; /* access mode*/ ushort seq; /* slot usage sequence number*/ key_t key; /* key*/ }
The three ctl system calls are used to access this structure and modify it. The three get system call, which create or open an IPC channel (also referred to as objects in the operating system), take a key value of type key_t, and return an integer identifier. An IPC key is a long integer used to name the IPC resource. A key is assigned by the programmer or by the system via the ftok system call, which returns a system V IPC key (for more details about ftok you can look at the UNIX man pages). The mode member of the ipc_perm structure defines, with its lower 9 bits, the access permissions to the resource for a process executing an IPC system call.
The interpretation of the permissions are summarized in the following tables:
Flags Description IPC_CREATE Create a new object for the specified key, if it does not already exist, or return it if the object exists. IPC_CREATE & IPC_EXCL This flag creates an IPC channel given a key. It returns an error if the object with the specified key already exist. This flag prevents to two unrelated processes from crating two channels with the same key. IPC_PRIVATE (note that this Guarantees that a unique IPC object is created. is key_t type) IPC_RMID Given an resource ID, this flag removes it from the system. The calling process must have the permissions on the object to be able removing it. IPC_STAT Given an resource ID, this flag returns the values of each member of an IPC object specified in the structure ipc_perm IPC_NOWAIT Return error is a request must wait IPC_SET Given an ID and a data structure for an object, this flag sets the values of each member of the corresponding
7 IPC object Table 3 Summary of the access permissions
When a new object is created using one of the get system calls with the IPC_CREAT flag as argument, the low-order 9 bits of the flag argument initialize the member mode in the ipc_perm structure. Additionally, the structure members cuid and uid are set to the effective user ID. The structure members gid and cgid further are set to the effective group ID of the calling process. The ipc_perm structure also contains a member variable called seq. This variable is a counter kept by the kernel for every possible IPC object in the system. The kernel increments this counter every time an IPC channel is closed. When it overflows the counter is reset to zero.
SEMAPHORES
One of the problems involved in multi-process applications is the need to synchronize various transactions between the processes. One way to solve this problem is communicate by socket, messages queues or pipes. However, sometimes exists the need to synchronize operations between several processes, or control the access to resources that may be shared by several processes in parallel, in order to prevent potentially erroneous read/write situations. The system V IPC primitive semaphore allows us to synchronize such operations. A semaphore is simply a counter provided by the kernel. The value of the variable at any time is the number of resource units available.
SHARED MEMORY
When two processes wants to communicate, they have to send the information through the kernel. If we consider the normal steps involved in a client-server file copying using pipes, FIFO or messages queues, a total of four copies of data are required:
The server reads from the input file. The kernel read the data and put it into one of its internal block buffers. Then copied it from this block to the server’s buffer by the read system call. The server writes the data to a message. Using a pipe, a FIFO or a message queue the data requires to be copied from the user’s buffer into the kernel The client reads the data from the IPC object. The client as well as the server requires copying the data from the kernel into its own buffer. The data contained in the client’s buffer is copied to the output file. We can do this by the write system call
To go around this problem, the shared memory facility lets two or more processes share a memory segment. We declare a given section in the memory as one that will be used simultaneously by several processes. This brings up the following problem: How the processes have to coordinate the use of the memory among themselves. What it is about here is to prevent a dirty read/write. In other words when a process is writing onto some shared memory, all other process that also share the same segment have to wait until the writing process is finished. The answer to this question is the use of semaphores for the synchronization. This result in only two
8 data copying: from the input file into the share memory and from the shared memory to the output file. As we said before, a shared memory segment is uniquely identified by a positive integer and has an associated data structure of type struct shmid_ds, defined in
9 struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ int shm_segsz; /* size of segment (bytes) */ time_t shm_atime; /* last attach time */ time_t shm_dtime; /* last detach time */ time_t shm_ctime; /* last change time */ unsigned short shm_cpid; /* pid of creator */ unsigned short shm_lpid; /* pid of last operator */ short shm_nattch; /* no. of current attaches */ }; The following system calls are provide by the system to work with shared memory: int shmget(key_t key, int size, int smhflag);
The call gets a key for the segment, the desired segment size, in bytes, and flags to indicate access permissions. The value returned by this call is the shared memory identifier, shmid, or –1 if an error occurs.
char *shmat(int shmid, char *shmaddr, int shmflag);
This system call returns the starting address of the shared memory segment. This call gets an shmid containing an identifier returned by a call to shmget, the attaching address specified by shmaddr and the shmflag that specifies in which mode the segment will be attached.
int shmctl(int shmid, int cmd, struct shmid_ds *buf);
This system call allows the calling process to receive information on a shared memory segment, set the owner, group, and permissions of a shared memory segment, or destroy it. The information about the segment identified by shmid is returned in the shmid_ds buf buffer. The returned value is 0 if the operation is successful, otherwise the value is –1.
MESSAGES QUEUES
In the system V implementation of messages, all messages are stored in the kernel, and every one is associated to a message queue identifier, a type. So, we can identify a particular queue of messages by this queue identifier. A message queue can be either private or public. A private queue can only be accessed by its creating process or by child processes of that creator. In contrast to both pipe and FIFO implementation, there are not requirements that any process must wait for a message to arrive on a queue before some other process is allowed to write a message to that queue. This means that, it is possible for a process to write some message to a queue and then exit. The message later can be read by another process that can access this message queue. IPC messaging passing lets processes send and receive messages, and queue messages for processing in an arbitrary order. Again, in contrast to pipe’s and FIFO’s file byte-stream data flow, each IPC messages has an explicit length. Because of the message’s specific type, a server process can direct message traffic between clients on its queue by using the client process PID as the message type. For example, if we have a server communicating with two client processes A and B, so the server has the possibility to read a message from the process B even if the process A has a message first in the queue.
10 Before a process can send or receive a message, the queue must be initialized. This means that if the queue does not exist, it must firstly be created; or if it exists, we have to initialise it to access it. This can be done by the system call
int msgget(key_t key, int msgflag);
Processes that request access to an IPC object must be able to identify it. This can be done by the functions that initialize or provide access to this object via the key argument in the system call. The second parameter contains the flag msgflag, which controls how the system call is to be processed. It may contain values like IPC_CREAT or IPC_EXCL, and access permissions bits defined before. The returned value by msgget is the message queue identifier msqid, or –1 if an error occurred.
Once a message is initialized, we can put a message on the queue using the msgsnd system call.
int msgsnd(int msqid, struct msgbuf *ptr, int length, int flag);
Each message is made up of, at least, two parts, which are defined in the template structure struct msgbuf as defined in sys/msg.h:
struct msgbuf { long mtype; char mtext[1]; };
The field mtype is used later when retrieving messages from the queue, and can be set to any positive number. The data portion of the message is not restricted to text. Any form of data is allowed. This means that the struct msgbuf may contain several variable members. So, the ptr argument points to a long integer that contains the message type, followed by the message itself.
The length argument to msgsnd system call specifies the length of the message in bytes. This is the length of the user-defined data that follows the long integer message type. So, if we use the C function sizeof(struct msgbuf), we must decrease by 4 the return value of sizeof. The flag argument can be specified as either IPC_NOWAIT or as zero. The IPC_NOWAIT value allows the system call to return immediately if there is no space the message queue for the new message. In this case the system call returns –1, otherwise it returns zero.
The followings are system limits affecting a msgsnd system call:
MSGMAX : Maximum size for a message text: the implementation set this value to 4080 bytes.
MSGMNB : Default maximum size in bytes of a message queue: policy dependent. The super-user can increase the size of a message queue beyond MSGMNB by a msgctl system call.
For reading a message from the message queue we can use the msgrcv system call
11 int msgrcv(int msqid, struct msgbuf *ptr, int length, long msgtype, int flag );
The msqid, *ptr, length, and the flag argument are defined as before. The msgtype argument is defined as:
0 – the fist message on the queue will be returned A positive integer - the first message on the queue whose type equals this integer A negative integer – the first message on the queue whose type is less then or equal to the absolute value of this integer
On successful return, msgrcv returns the number of bytes of data in the received message. This does not include the long integer message type that is also returned through the ptr argument.
There is also a system call for controlling the permissions and other characteristics of a message queue: msgctl
int msgctl(int msqid, int cmd, struct msgbuf *buff );
The cmd argument is one of the following:
IPC_STAT: Places information about the status of the queue in the data structure pointed by buff. The calling process must have read permission on the queue for this call to succeed IPC_SET: Sets the owner’s user and group ID, the permissions, and the size (in number of bytes) of the message queue. A process IPC_RMID: Removes the message queue specified by the msqid argument
CGI
The Common Gateway Interface (CGI) is a standard method for a Web browser and a CGI program running on a Web server to communicate. CGI was developed to meet the demand of doing web pages more interactive. People wanted to be able to collect information from the clients, for example, to take orders or allow database lookups from the sever, etc. A CGI program is a program, which “knows” how to receive information from the Web server; how to processes it and sends a reply back. The CGI program does not communicate with the browser directly, but by the Web server. It is the Web server that connects the GCI application (a program or a script) with the client browser. CGI is essentially the minimum that a Web server needs to provide in order to allow external process to create web pages. In this sense CGI can be defined as a standard for interfacing external applications with information servers, such as HTTP or Web servers. When a Web server receives a request for a CGI application, submitted via an HTML page classified as either a “GET” or “POST”, executes the CGI application, just as another process with the incoming parameters, collects the process output and sends them as a static html file. A CGI program takes its inputs from environment variables and standard input, stdin, and sends its output to standard output, stdout. From the application’s point of view, stdin is what comes from the browser via the server when a POST or GET method is used. stdout is where the application writes its output back to the browser.
12 The HTML tag “ form” is used to submit data to a CGI program
Everything between the