ALTERNATE SERVER AND MESSAGE PASSING

A PROJECT REPORT Submitted by

P.BALAMURUGAN (30605104012) G.KARTHICK (30605104023)

in partial fulfillment for the award of the degree

of

BACHELOR OF ENGINEERING
in COMPUTER SCIENCE AND ENGINEERING JEPPIAAR ENGINEERING COLLEGE, CHENNAI 600 119

ANNA UNIVERSITY: CHENNAI 600 025

MAY 2009 i

JEPPIAAR ENGINEERING COLLEG DEPARTMENT OF COMPUTER SCIENCE AMD ENGINEERING JEPPIAAR NAGAR, OLD MAMALLAPURAM ROAD, CHENNAI-600 119

BONAFIDE CERTIFICATE Certified that this project report ALTERNATE SERVER AND
MESSAGE PASSING is the bonafide work of P.BALAMURUGAN (30605104012) and G.KARTHICK (30605104023) who carried out the project work under my supervision.

Submitted for the examination held on

PROJECT GIUDE

HEAD OF THE DEPARTMENT

INTERNAL EXAMINER

EXTERNAL EXAMINER

ii

DEDICATED TO OUR BELOVED PARENTS AND FRIENDS

ACKNOWLEDGEMENT

ACKNOWLEDGEMENT
I am very much indebted to our chairman, Thiru Dr. Jeppiaar M.A., B.L., Ph.D., and the Secretary Thiru. P. Chinnadurai M. Phil., B. Ed., the Directors Thiru N. Marie Wilson B. Tech., M.B.A., (Ph.D) and Mrs. Regeena Wilson B. Tech., M.B.A., (Ph.D) Principal Dr. Sushil Lal Das M.Sc., (Engg)., Ph.D., for providing me an excellent infrastructure and valuable resources for carrying out this project.

I wish to thank our Head of the Department, Project Coordinator and Internal Guide for their guidance towards the successful completion of he project.

Last but not the least, I wish to acknowledge my parents for their kind support and being with me at my times of sorrow and also for bringing me coffee whenever I wanted.

ABSTRACT

ABSTRACT The UNIX operating system trades upon the labels of security and reliability. While the best possible security is availed through the File Management System, trademarks such as the proxy-server and the alternate sever is responsible for its reliability thus making UNIX has so far the dominant operating system of the emerging era. Our focus on the implementation of an Alternate Sever. The Client is the process that requests service from a remote process known as the Server which sends back the reply to the client. In case the Server crashes then there lies a breakdown in the entire system left with the client unable to communicate. This can be indicated by sending signals. The main server gets detached and the signals are also stopped. To avoid such a crisis we go for a Backup-Server which maintains the connection status of the Client and is updated then to then such that the connection may be resume with the Alternate Server acting as the Main-Server. The clients are connected automatically to the alternate server by sending the signals. The alternate server is the second client of the main server. The information that is maintained by the main server is updated to the alternate server. The updation is carried out by the constant time intervals. The alternate server assumes that the main server crashes and the alternate server take part of the communication process.

TABLE OF CONTENTS

TABLE OF CONTENTS
CHAPTER NO TITLE PAGE NO

ABSTRACT LIST OF FIGURE LIST OF TABLES 1. INTRODUCTION 1.1 Server Crashing 1.2 Alternate Server 2. 3. LITERATURE REVIEW SYSTEM ANALYSIS 3.1 Existing System 3.2 Proposed System 3.3 Problem Description 4. SOFTWARE HARDWARE ENVIRONMENT 4.1 Operating System 4.1.1 LINUX operating system 4.1.2 Red Hat Linux 5.1 4.1.3 History of LINUX 4.2 About the language 4.2.1 UNIX operating system 4.2.2 UNIX environment 4.3 Hardware Description 4.4 Software Description

iii vi vii 1 1 2 4 5 5 5 6 7 7 7 7 8 9 9 10 10 11

5.

SYSTEM DESIGN 5.1 Block Diagram 5.2 Data Flow Diagram 5.3 Socket programming 5.3.1 Socket Creation and Naming 5.3.2 Connecting Stream Sockets 5.3.3 Datagram Sockets 5.3.4 Socket Options 5.4 Signals 5.4.1 Handling Signals

12 12 15 17 19 21 22 25 26 27 28 28 29 30 30 31 32 33 34 36 40 46 49 50 51 51 61

6.

PROJECT DESCRIPTION 6.1 Main server 6.2 Alternate Server 6.3 Client 6.4 Structured used 6.4.1 Pre Defined Structure 6.4.2 User Defied structure 6.5 File handling 6.5.1 Function Used 6.6 Signals 6.7 Client Server Model

7. 8. 9. 10.

TESTING AND IMPLEMENTATION CONCLUSION REFERENCE APPENDIX 10.1 Coding 10.2 Screen Shots

LIST OF FIGURES

LIST OF FIGURE

FIG NO

TITLE OF FIGURE

PAGE NO

5.1.1

AITERNATE SERVER AND MESSAGE PASSING 12 13 14 15 16

5.1.2 5.1.3 5.2.1 5.2.2 5.3.1(a)

BEFORE SERVER CRASHING AT THE TIME OF SERVER CRASHING DATAFLOW DIAGRAM FAILURE OF THE MAIN SERVER STATE TRANSTITION OF SERVER STREAM SOCKET

20

5.3.1(b)

STATE TRANSTITION OF CLIENT STREAM SOCKET 22 23

5.3.3(a) 5.3.3(b)

STATE TRANSTITION OF DATAGRAM SOCKET ALTERNATE STATE TRANSTITION OF DATAGRAM SOCKET

24 25

5.3.4

OSI LAYER

vi

LIST OF TABLES

LIST OF TABLES

TABLE NO 1.1

TITLE OF TABLE MACRO SIGNALS HEADER FILES

PAGE NO

37

vii

Chapter 1

INTRODUCTION

1. INTRODUCTION

1.1 SERVER CRASHING Network file servers have multiple clients to take care of. If two or more clients should accidentally happen to decide to access the same file at more or less the same time, problems can occur. One widely implemented solution is to permit clients to lock files before using them. But locking introduces several annoying problems. One of them is when the server crashes. After the server restarts, no locks are remembered. Crashing also causes several other problems. When the client is in the process of receiving an important file from a remote file server and if the file server happens to crash, the file transfer process will be affected entirely. The file transfer can be started once again from the beginning. In this case, a large amount of data that has been previously transferred prior to the crash will be transferred once again causing redundancy. The file server can retain the information about the last set of bytes that has been transferred and continue from the next set of bytes. This solution can have many synchronization problems. Moreover, this process may turn out to be more complicated when the number of clients is more. Crashing of server can also be more problematic if the server is used for transferring messages between the clients in a small network. When a client sends the message and the destination clients name to the server and after receiving the message, if the server happens to crash then the message will never be transferred to the receiver and the sender will never come to know of this.

So to counter these problems associated with the server crashing, we have proposed the idea of implementing an Alternate Server which overcomes all these inherent problems. 1.2 ALTERNATIVE SERVER

In this proposed system the alternate server takes the role of a backup to the main server. As the operations carried out by the main server (File Transfer & Message Transfer) are of utmost importance and its crashing may cause serious problems the server engages a separate host to act as its backup. This host termed as the Alternate Server is dedicated solely to this particular main server.

Initially when a client wants to log on to the main server, it connects to the appropriate port number of the main server. The alternate server will be the first client to connect to the main server. This is how the main server distinguishes the Alternate Server from the rest of its clients. The clients are not aware of the fact that an alternate server exists.

The server performs its bookkeeping operations by constantly sending the Alternate Server of its status i.e. the status of its operations with each of its clients at regular intervals. The Alternate Server receives the status of the main server and updates the information in a separate file. The interval can be set to any desired value.

In addition to being the first client of the main server, the alternate server should also act as the server for the clients as soon as the main server crashes. So

the alternate server is bound to another port number and IP address where it listens for the clients to connect to it. Once the main server crashes, the clients will connect to the port number and IP address to which the alternate server is bound. The alternate server then resumes the operations for each of the clients at the stage where they were interrupted when the main server crashed.

After the server crash, the alternate server will be able to accept any new client which connects for request. The alternate server may continue to process the clients requests till the main server restarts after which the clients may connect to the main server once again. ALTERNATE-SERVER contained a domain name rather than an IP address and port.

Chapter 2

LITERATURE REVIEW

2. LITERATURE REVIEW
The main objective of the proposed system is to overcome the problem of server crashing. This project mainly deals with the transfer of files during the server crashing. This is very useful, because the server is the main part for the transfer of files.

When the server gets crashed, there is no other way to resolve it. More number of file is transferred at the same time. It also concentrates on the message passing. The files are transferred by made the request by the clients. The server maintains the status of the client and the files.

This is done through Linux using the Unix C coding. The Linux is very effective for this project. As the UNIX system has spread, the fraction of its users who are skilled in its application has decreased. Time and again, the language find only clumsy solutions to a problem are write programs to do jobs that existing tools handle easily. Of course, the elegant solutions are not easy to see without some experience and understanding.

The UNIX system has become very popular, and there are a number of versions in wide use. The UNIX system, though certainly not perfect, is a marvelous computing environment. In a broader sense, UNIX is often taken to include not only the kernel, but also essential programs like compilers, editors, and command languages, programs for copying and printing files and so on.

Thus the UNIX system is well suited for this project. By implementing this project, the redundancy is reduced which is the major advantage.

Chapter 3

SYSTEM ANALYSIS

3. SYSTEM ANALYSIS
3.1 EXISTING SYSTEM

In the existing system, there is a lack of fault tolerance.

In the network file transfer processing, the server is the main part for the reliable transfer.

The files are transferred from one client to another through the servers. The servers maintain the status of the clients and the information about the files.

So many files are transferred at the same time. During the process when the server gets crashed, the server is switched off and it is rebooted from its initial stage.

It is slightly difficult to achieve the reliability in the file transferring process

3.2 PROPOSED SYSTEM As system like this has been implemented in any other platform so for.

The whole project is based on UNIX OS, which is more versatile and secure than windows environment.

In the event of failure of any kind with the main server the whole

network will be restored in no-time with the implementation of this system

In this method, the alternate server is the backup of the main server. When the main server is crashed, the signals are passed from the main server to the alternate server are stopped and the alternate server is activated.

All the clients that are connected to the main server are automatically connected to the alternate server by modify its port address.

The files that are requested by the clients are transferred accurately to its destination file address.

The alternate server is activated from the time of the crashing of main server.

3.3 PROBLEM DESCRIPTION

The problem in the existing is that when the main server is crashed it is rebooted again.

In this case, the file that is transferred at the time of crashing is again transferred from the starting bytes.

Due to this, the redundancy will be occurred. By the introduction of the proposed system, the redundant will be reduced to a large extent.

Chapter 4

SOFTWARE AND HARDWARE ENVIRONMENT

4. SOFTWARE AND HARDWARE REQUIREMENTS 4.1 OPERATING SYSTEM 4.1.1 LINUX Operating Systems LINUX is an Operating System for several types of computer platforms, but primarily for Intel-based PCs. The system has been designed and built by hundreds of programming scattered around the world. The goal has been to create a UNIX clone, free of any commercially copyrighted software, which the entire world can use. 4.1.2 Red Hat Linux 5.1 Linux is an OS, which acts as a communication service between the hardware (or physical equipment of computer) and the software (or applications which uses the hardware) of a computer system. Linux is distributed under the terms of the Free Software Foundations GNU General Public License or GPL. This license preserves software copyrights, but ensures distribution of programs with source code. Linux is distributed over the Internet, and is easy to download, upgrade and share. New features of the latest versions of the Linux kernel and the distribution include the following: Increase support for a wide variety of devices such as sound cards, scanners, hard disks, tape drives, printers, digital cameras and joy sticks.

Increasingly easier installation, configuration and system maintenance with dozens of different GUI program, many of which surpass commercial software peers in convenience and ease of use. 4.1.3 History of LINUX Linux started out as a UNIX variant for the IBM PC architecture. The initial version was written by Linus Torvalds, a Finnish student of computer science. Torvalds posted an early version of Linux on the Internet in 1991. Since then, a number of people, collaborating over the Internet, have contributed to the development of Linux, all under the control of Torvalds. Because Linux is free and the source code is available, it became an early alternative to other UNIX workstations, such as those offered by Sun Microsystems, Digital Equipment Corp Compaq), and Silicon Graphics. Today, Linux is a full-featured UNIX system that runs on all of these platforms and more. Key to the success of Linux has been its character as a free package available under the auspices of the Free Software Foundation (FSF). FSF's goal is stable, platform-independent software that is free, high quality, and embraced by the user community. FSF's GNU project provides tools for software developers, and the GNU Public License (GPL) is the FSF seal of approval. Torvalds used GNU tools in developing his kernel, which he then released under the GPL. Thus, the Linux distributions that you see today are the product of FSF's GNU project, Torvalds individual effort, and many collaborators all over the world. In addition to its use by many individual programmers; Linux has now made significant penetration into the corporate world [MANC00]. This is not primarily because of the free software, but because of the quality of the Linux kernel.

Many talented programmers have contributed to the current version, resulting in a technically impressive product. Moreover, Linux is highly modular and easily configured. This makes it easy to squeeze optimal performance from a variety of hardware platforms. Plus, with the source code available, vendors can tweak applications and utilities to meet specific requirements. 4.2 ABOUT THE LANGUAGE Unix is a time sharing operating system kernel a program that control the sources of a compiler and allocates them among its users .The Unix operating system is rich and productive .Even though, the Unix system introduces a number of innovative programs and mechanisms, no single program or idea makes it work well .The thing which makes it effective is an approach to programming, a philosophy of using the computer. The special features of UNIX are, Because it is written in C, it is portable UNIX systems run on a range of computers from microprocessors to the largest mainframes. This is the strong commercial advantage. The source code is available and written in a high-level language, which makes system easy to adapt to particular requirements. Most important, it is a good operating system especially for programmers. 4.2.1 UNIX Operating System UNIX is an operating system that allows a user and a computer to interact. Initially developed at Bell Laboratories in the early 1970s, we (yes, the University of California Berkeley) made many enhancements to the program and

our version of UNIX began to diverge from the Bell Labs version. Today, there are many different versions of UNIX. UNIX is a general, multi-tasking, multi-user, Interactive operating system. The UNIX system uses a prompt to tell you it is ready to accept your next command. You must always finish a command by hitting return (or enter). This is similar to a prompt you would see if you were using DOS on a PC/IBM machine. The prompt in UNIX is usually your email address or the machine name, followed by the number of times youve seen the prompt during your current session. An important note on UNIX: it is case sensitive!! This means that when logging in, your password may be g0be8rs but if you type in G0BE8RS UNIX will not recognize it as correct.

4.2.2 UNIX environment UNIX saves everything in files and directories. If youre familiar with Windows or DOS, youll be happy to know that UNIX works almost exactly the same as Windows and DOS when it comes to files and directories. A file is a bunch of information stored together, like all the characters you typed for your paper for Underwater Basket Weaving 112C. A directory is a container for files (equivalent to a folder for Windows 95 or Mac gurus). The computer organizes the files like a file cabinet, with different drawers, folders, and also files within the folders. Just imagine if you worked in an office where everyone threw their work in one big pile in the corner!! With file cabinets (and the file/directory structure in UNIX) we dont have that problem! 4.3 HARDWARE DESCRIPTION To develop this system the IBM compatible personnel computer with a Pentium III process was used.

Main processor Cache Hard disk Floppy drive CD drive Monitor RAM Keyboard Mouse

: Intel Dual core 3.3 MHZ : 250 KB : 120 GB : 1.44 MB : 52X CD-ROM : 17 LCD Color Monitor : 1 GB : Samsung : Logitech

4.4 SOFTWARE DESCRIPTION The main purpose of software description is the clear definition and specification functionality and of the interface of the software product. The software specification are the only basic for the manuals, documentation and product catalogues etc.Its helps the developer or the analyst to understand the system , function to be established. Operating System : Linux. UNIX

Programming Language :

Chapter 5

SYSTEM DESIGN

5. SYSTEM DESIGN
5.1 BLOCK DIAGRAM

Fig 5.1.1 ALTERNATE SERVER AND MESSAGE PASSING

Fig 5.1.2 BEFORE SERVER CRASHING

Fig 5.1.3 AT THE TIME OF SERVER CRASHING

5.2 DATA FLOW DIAGRAM Registration & Transaction

Registration Request Message

CLIENT DATABASE

CONNECTIN G CLIENT

Reply

Data Request

TRANSACTIO N IN SERVER

SERVER DB

Fig 5.2.1 REGISTRATION AND TRANSACTION

 FAILURE

SIGNAL MESSAGES BY ALTERNATE SERVER AT PERIODIC INTERVALS BY TIME

Signal
VALIDITY BY SIGNAL

Signal

Transaction update message

CONTINUE WITH EXISTING SYSTEM

No
CONNECT CLIENT WITH ALTERNATE SERVER

Yes

Server Failure

LOG FILE

Fig 5.2.2 FAILURE OF THE MAIN SERVER

5.3 SOCKET PROGRAMMING Sockets provide point-to-point, two-way communication between two processes. Sockets are very versatile and are a basic component of interprocess and intersystem communication. A socket is an endpoint of communication to which a name can be bound. It has a type and one or more associated processes. Sockets exist in communication domains. A socket domain is an abstraction that provides an addressing structure and a set of protocols. Sockets connect only with sockets in the same domain. Twenty three socket domains are identified (see <sys/socket.h>), of which only the UNIX and Internet domains are normally used Solaris 2.x Sockets can be used to communicate between processes on a single system, like other forms of IPC. The UNIX domain provides a socket address space on a single system. UNIX domain sockets are named with UNIX paths. Sockets can also be used to communicate between processes on different systems. The socket address space between connected systems is called the Internet domain. Internet domain communication uses the TCP/IP internet protocol suite. A Socket types define the communication properties visible to the application. Processes communicate only between sockets of the same type. There are five types of socket. A stream socket

-- provides two-way, sequenced, reliable, and unduplicated flow of data with no record boundaries. A stream operates much like a telephone conversation.

The socket type is SOCK_STREAM, which, in the Internet domain, uses Transmission Control Protocol (TCP).

A datagram socket

It supports a two-way flow of messages. A on a datagram socket may receive messages in a different order from the sequence in which the messages were sent. Record boundaries in the data are preserved. Datagram sockets operate much like passing letters back and forth in the mail. The socket type is SOCK_DGRAM, which, in the Internet domain, uses User Datagram Protocol (UDP).

A sequential packet socket

Its provides a two-way, sequenced, reliable, connection, for datagrams of a fixed maximum length. The socket type is SOCK_SEQPACKET. No protocol for this type has been implemented for any protocol family.

A raw socket

A raw sockets are provides access to the underlying communication protocols. These sockets are usually datagram oriented, but their exact characteristics depend on the interface provided by the protocol.

5.3.1 Socket Creation and Naming int socket(int domain, int type, int protocol) is called to create a socket in the specified domain and of the specified type. If a protocol is not specified, the system defaults to a protocol that supports the specified socket type. The socket handle (a descriptor) is returned. A remote process has no way to identify a socket until an address is bound to it. Communicating processes connect through addresses. In the UNIX domain, a connection is usually composed of one or two path names. In the Internet domain, a connection is composed of local and remote addresses and local and remote ports. In most domains, connections must be unique. int bind(int s, const struct sockaddr *name, int namelen) is called to bind a path or internet address to a socket. There are three different ways to call bind(), depending on the domain of the socket.For UNIX domain sockets with paths containing 14, or fewer characters, you can:

#include <sys/socket.h> ...

bind (sd, (struct sockaddr *) &addr, length); If the path of a UNIX domain socket requires more characters, use: #include <sys/un.h> ...

bind (sd, (struct sockaddr_un *) &addr, length); For Internet domain sockets, use #include <netinet/in.h> ...

bind (sd, (struct sockaddr_in *) &addr, length);

In the UNIX domain, binding a name creates a named socket in the file system. Use unlink() or rm () to remove the socket.

Fig 5.3.1 (a) STATE TRANSITION OF SERVER STREAM SOCKET

5.3.2 Connecting Stream Sockets Connecting sockets is usually not symmetric. One process usually acts as a server and the other process is the client. The server binds its socket to a previously agreed path or address. It then blocks on the socket. For a SOCK_STREAM socket, the server calls int listen(int s, int backlog) , which specifies how many connection requests can be queued. A client initiates a connection to the server's socket by a call to int connect(int s, struct sockaddr *name, int namelen) . A UNIX domain call is like this: struct sockaddr_un server; ... connect (sd, (struct sockaddr_un *)&server, length); while an Internet domain call would be: struct sockaddr_in; ... connect (sd, (struct sockaddr_in *)&server, length); If the client's socket is unbound at the time of the connect call, the system automatically selects and binds a name to the socket. For a SOCK_STREAM socket, the server calls accept(3N) to complete the connection. int accept(int s, struct sockaddr *addr, int *addrlen) returns a new socket descriptor which is valid only for the particular connection. A server can have multiple SOCK_STREAM connections active at one time.

Fig 5.3.1(b) STATE TRANSITIONS OF A CLIENT STREAM SOCKET

5.3.3 Datagram Sockets A datagram socket does not require that a connection be established. Each message carries the destination address. If a particular local address is needed, a call to bind() must precede any data transfer. Data is sent through calls to sendto() or sendmsg(). The sendto() call is like a send() call with the

destination address also specified. To receive datagram socket messages, call recvfrom() or recvmsg(). While recv() requires one buffer for the arriving data, recvfrom() requires two buffers, one for the incoming message and another to receive the source address.

Fig 5.3.3 (a) STATE TRANSITION OF A DATAGRAM SOCKET Datagram sockets can also use connect () to connect the socket to a specified destination socket. When this is done, send () and recv () are used to send and receive data.

Fig 5.3.3 (b) ALTERNATE STATE TRANSITION OF A DATAGRAM SOCKET

accept () and listen () are not used with datagram sockets.

5.3.4 Socket Options A Sockets have a number of options that can be fetched with getsockopt() and set with setsockopt(). These functions can be used at the native socket level (level = SOL_SOCKET), in which case the socket option name must be specified. To manipulate options at any other level the protocol number of the desired protocol controlling the option of interest must be specified (see getprotoent() in getprotobyname()).

Application Layer (RPM Server)

Application Layer (RPM Server)

Transport Layer (UDP)

Transport Layer (UDP)

Network Layer (IP)

Network Layer (IP)

Link Layer & Physical Layer

Link Layer & Physical Layer

Transmission Line

Fig 5.3.4 OSI LAYERS

 This is achieved by means of socket. A socket is an end point for communication in an application program. Socket is an end point abstraction of a network connection. A socket is made to associate with a port number through which it will be able to communicate with the other end of the connection.

Sockets can be created and destroyed dynamically. Creating a socket returns a socket descriptor which is needed for establishing a connection. Each socket supports a particular type of networking specified when the socket is created.

The most common types are, Reliable Connection Oriented Byte Stream Reliable Connection Oriented Packet Stream Unreliable Packet Stream After creating a socket with one of the above special types it is bound to a 32 bit integer.

5.4 SIGNALS Signals inform processes of the occurrence of asynchronous events. Processes may send each other signals through the KILL system call. The signals may be classified as follows: Signals having to do with the termination of a process. Signals having to do with the processes that cause exceptions. Signals having to do with unrecoverable error conditions during a system call.

 Signals originating from a process that receives an alarm signal after an interval of time. Signals for tracing execution of process. To send a signal to a process the kernel sets a bit in the signal field of the process table entry corresponding to the type of the signal. A process can remember different type of signals but it has no memory of how many signals it receives of a particular type. If a process receives a hang-up signal and a kill signal it sets the corresponding bits in the process table signal field but it cant remember how many instances of the signals it receives.

5.4.1 HANDLING SIGNALS There are three cases for handling signals via, Process exits on receipt of the signal Process can ignore the signal Process executes a particular function on the receipt of the signal The default action is to call exit in kernel mode. But a process can specify a special action to take on receipt of certain signals with the signal system call The syntax for the signal system call Oldfunction=signal (signum,function) Where signum is the signal number the process is specifying the action for, function is the address of the user function the process wants to invoke on receipt of the signal and the return value oldfunction is the value of function in the most recently specified call to signal for signum.

Chapter 6

PROJECT DESCRIPTION

6. PROJECT DESCRIPTION 6.1 MAIN SERVER

The main server first changes its process group id in order to send signals to all the child processes. Then it calls the set timer function to initiate timer so that it sends the SIGNALRM at regular intervals. Once the parent receives this signal it sends a signal to all the processes in its group. The parent process also receives this signal and on receiving it waits at the end of the unnamed pipe created by the parent process itself. The child processes on receiving the signal from the parent process write their corresponding status into the pipe one by one. The parent process then reads from the piped one by one and sends them to the alternate server.

The parent process creates a child process for each of the client logged in. The child process receives the request from the corresponding client and processes it. It checks whether request is for file transfer or for message transfer. If the request is for file transfer the child, process checks whether the file exists or not. If the file exists, the child process opens the file, reads the content of the file and transfers them to the client. For every thousand bytes sent, the main server sends a signal to the alternate server. So when the main server crashes during the file transfer, the alternate server resumes the file transfer by reading the status. At most, there will be a redundancy of thousand bytes, which can be reduced by sending the signal after 100 bytes.

6.2 ALTERNATIVE SERVER

In this proposed system the alternate server takes the role of a backup to the main server. As the operations carried out by the main server (File Transfer & Message Transfer) are of utmost importance and its crashing may cause serious problems the server engages a separate host to act as its backup. This host termed as the Alternate Server is dedicated solely to this particular main server.

Initially when a client wants to log on to the main server, it connects to the appropriate port number of the main server. The alternate server will be the first client to connect to the main server. This is how the main server distinguishes the Alternate Server from the rest of its clients. The clients are not aware of the fact that an alternate server exists.

The server performs its bookkeeping operations by constantly sending the Alternate Server of its status i.e. the status of its operations with each of its clients at regular intervals. The Alternate Server receives the status of the main server and updates the information in a separate file. The interval can be set to any desired value.

In addition to being the first client of the main server, the alternate server should also act as the server for the clients as soon as the main server crashes. So the alternate server is bound to another port number and IP address where it listens for the clients to connect to it. Once the main server crashes, the clients will connect to the port number and IP address to which the alternate server is bound. The alternate server then resumes the operations for each of the clients at the stage where they were interrupted when the main server crashed.

After the server crash, the alternate server will be able to accept any new client which connects for request. The alternate server may continue to process the clients requests till the main server restarts after which the clients may connect to the main server once again. 6.3 CLIENT The client performs normal transaction with the main server until it crashes. On file crash, all the clients connect to the alternate server. Before connecting the value of the port number and IP address are modified to that of the alternate server. The user who is logged as the client will not be aware of this fact. Moreover, when a new client tries to log to the main server, the client host will connect to the alternate server only.

6.4 STRUCTURES USED 6.4.1 PREDEFINED STRUCTURES Socket address structure SOCKADDR_IN This structure is defined in <sys/socket.h>. This value for this structure is value as soon as the connection is established. struct sockaddr_in { short sin_family; u_short sin_port; struct in_addr sin_addr; /*AF_INET*/ /*16-bit port no., network byte ordered*/ /*32-bit host id, network byte ordered*/

char sin_zero[8]; };

/*unused*/

Timer structure ITIMERVAL. This structure is contained in <sys/time.h> struct itimerval { struct timeval it_interval; strcut timeval it_value; }; struct timeval { long tv_sec; long tvusec; }; /*seconds*/ /*microseconds*/ /*next value*/ /*current value*/

6.4.2 USER DEFINED STRUCTURES

Server status attributes SERVSTAT. This structure is used to send the status of all the clients to the alternate server. struct servstat { int ch; int bytes; char m; char file[20]; char mess[50]; } /*child identifies*/ /*no. of bytes transferred*/ /*identifies file transfer/message transfer */ /*file name of transferring file (m=f)*/ /*message being transferred (m=c)*/

6.5 FILE HANDLING LIST OF FILES CLILIST.TXT This file contains the list of names of all the clients who have been

logged in and is maintained by the main server. When a new client logs in the server gets the name from the client and checks it with the list of name in this file. If the name already exists then the server asks the client to send a new name. This continues until the client sends a new name. Then the server makes entry of the name. CLILIST1.TXT This file is used by the alternate server and it contains the list of names of all the clients who have logged on to the main server. In addition to this the file also contains the list of client names who have logged after the crash. The alternate server also follows the same process of login for the clients. STATUS.TXT This file is used by the alternate server and it contains the status of the main server when the last signal was received from the main server. The alternate server updates the contents of this file every time on the receipt of the status information from the main server. When the main server crashes the alternate server uses the information contained in this file to resume the operations uncompleted by the main server.

6.5.1 FUNCTIONS USED SERVER.C Alterstat () This function is invoked by the parent process of the main server every t secs. This function performs the operation of obtaining the status of the client with the main server and sends each of the status to the alternate server. clistat () This function is invoked by each of the child process pertaining to each of the client. Through this function each of the clients sends its status to the parent process of the main server. This function is invoked every time alterstat () is invoked. Msg () This function is used by the parent process to transfer the message sent by one client to the destination client. The child process corresponding to the sender writes the message in to the pipe. The parent process gets the message from the pipe and transfers it to the destination client. Fork() A fork ( ) creates a child process that differs from the parent process only in its PID and PPID, and in the fact that resource utilizations are set to 0.

 ALTERSERVER.C Clistat () This function is invoked by each of the child process pertaining to each of the client. Through this function each of the clients sends its status to the parent process of the main server. This function is invoked every time alterstat () is invoked. msg () This function is used by the parent process to transfer the message sent by one client to the destination client. The child process corresponding to the sender writes the message in to the pipe. The parent process gets the message from the pipe and transfers it to the destination client. CLIENT.C new() This function is used by the client to connect to the alternate server. This function gets invoked when the main server crashes. Here the IP address and the port number are modified to that of the alternate server. associate() This function is used by the client to connect to the main server. This function is invoked initially when the client wants to log on to the main server. Here the IP address and the port number are assigned to that of the alternate server.

6.6 SIGNALS: <signal.h> In this section will look at ways in which two processes can communicate. When a process terminates abnormally it usually tries to send a signal indicating what went wrong. C programs (and UNIX) can trap these for diagnostics. Also user specified communication can take place in this way. Signals are software generated interrupts that are sent to a process when a event happens. Signals can be synchronously generated by an error in an application, such as SIGFPE and SIGSEGV, but most signals are asynchronous. Signals can be posted to a process when the system detects a software event, such as a user entering an interrupt or stop or a kill request from another process. A Signal can also be come directly from the OS kernel when a hardware event such as a bus error or an illegal instruction is encountered. The system defines a set of signals that can be posted to a process. Signal delivery is analogous to hardware interrupts in that a signal can be blocked from being delivered in the future. Most signals cause termination of the receiving process if no action is taken by the process in response to the signal. Some signals stop the receiving process and other signals can be ignored. Each signal has a default action which is one of the following:

The signal is discarded after being received The process is terminated after the signal is received A core file is written, then the process is terminated Stop the process after the signal is received

Each signal defined by the system falls into one of five classes:

Hardware conditions Software conditions Input/output notification Process control Resource control

Macros are defined in <signal.h> header file for common signals. These include:

SIGHUP 1 /* hang up */ SIGQUIT 3 /* quit */ SIGABRT 6 /* used by abort */ SIGALRM 14 /* alarm clock */ SIGCONT 19 /* continue a stopped process */ SIGCHLD 20 /* to parent on child stop or exit */

SIGINT 2 /* interrupt */ SIGILL 4 /* illegal instruction */ SIGKILL 9 /* hard kill */

Tab 1.1 Macro signals

Signals can be numbered from 0 to 31.

Sending Signals -- kill(), raise() There are two common functions used to send signals int kill(int pid, int signal) - a system call that send a signal to a process, pid. If pid is greater than zero, the signal is sent to the process whose process ID is equal to pid. If pid is 0, the signal is sent to all processes, except system processes. kill() returns 0 for a successful call, -1 otherwise and sets errno accordingly. int raise(int sig) sends the signal sig to the executing program. raise() actually uses kill() to send the signal to the executing program: kill(getpid(), sig); There is also a UNIX command called kill that can be used to send signals from the command line - see man pages. NOTE: that unless caught or ignored, the kill signal terminates the process. Therefore protection is built into the system. Only processes with certain access privileges can be killed off. Basic rule: only processes that have the same user can send/receive messages. The SIGKILL signal cannot be caught or ignored and will always terminate a process. For example kill(getpid(),SIGINT); would send the interrupt signal to the id of the calling process.

This would have a similar effect to exit() command. Also ctrl-c typed from the command sends a SIGINT to the process currently being. unsigned int alarm(unsigned int seconds) -- sends the signal SIGALRM to the invoking process after seconds seconds.

Signal Handling -- signal() An application program can specify a function called a signal handler to be invoked when a specific signal is received. When a signal handler is invoked on receipt of a signal, it is said to catch the signal. A process can deal with a signal in one of the following ways:

The process can let the default action happen The process can block the signal (some signals cannot be ignored) the process can catch the signal with a handler.

Signal handlers usually execute on the current stack of the process. This lets the signal handler return to the point that execution was interrupted in the process. This can be changed on a per-signal basis so that a signal handler executes on a special stack. If a process must resume in a different context than the interrupted one, it must restore the previous context itself Receiving signals is straighforward with the function: int (*signal(int sig, void (*func)()))() -- that is to say the function signal() will call the func functions if the process receives a signal

sig. Signal returns a pointer to function func if successful or it returns an error to errno and -1 otherwise. func() can have three values: SIG_DFL -- a pointer to a system default function SID_DFL(), which will terminate the process upon receipt of sig. SIG_IGN -- a pointer to system ignore function SIG_IGN() which will disregard the sig action (UNLESS it is SIGKILL). A function address -- a user specified function. SIG_DFL and SIG_IGN are defined in signal.h (standard library) header file. Thus to ignore a ctrl-c command from the command line. we could do: signal(SIGINT, SIG_IGN); TO reset system so that SIGINT causes a termination at any place in our program, we would do: signal(SIGINT, SIG_DFL);

6.7 Client-Server model The client-server model is used to divide the work of Internet programs into two parts. One part knows how to do a certain task, or to give a certain service. This part is called the Server. The other part knows how to talk to a user, and connect that user to the server. This part is called the Client. One server may give service to many different clients, either simultaneously, or one after the other (the server designer decides upon that). On the other hand, a Client talks to a single user at a time, although it might talk to several servers, if its nature requires that. There are other such complex possibilities, but we will discuss only clients that talk to a single server. Most networking applications are written assuming one side is the client and the other the server. The purpose of the application is for the server to provide some defined service for clients. We can categorize servers into two classes: iterative or concurrent. An iterative server iterates through the following steps. 1. Wait for a client request to arrive. 2. Process the client request. 3. Send the response back to the client that sent the request. 4. Go back to step 1. The problem with an interactive server is when step 2 takes a while. During this time no other clients are serviced. A concurrent server, on the other hand, performs the following steps.

Wait for a client request to arrive. 1. Start a new server to handle this client's request. This may involve creating a new process, task, or thread, depending on what the underlying operating system supports. How this step is performed depends on the operating system. This new server handles this client's entire request. When complete, this new server terminates. 2. Go back to step 1. The advantage of a concurrent server is that the server just spawns other servers to handle the client requests. Each client has, in essence, its own server. Assuming the operating system allows multi-programming, multiple clients are serviced concurrently 6.7.1 Roles of Clients A client's main feature is giving a convenient User interface, hiding the details of how the server 'talks' from the user. Today, people are trying to write mostly graphical clients, using windows, pop-up-menus and other such fancy stuff. We will leave this to someone else to explain, and concentrate on the networking part. The client needs to first establish a connection with the server, given it's address. After the connection is established, The Client needs to be able to do two things: 1. Receive commands from the user, translate them to the server's language (protocol) and send them to the server. 2. Receive messages from the server, translate them into human-readable form, and show them to the user. Some of the messages will be dealt with by the client automatically, and hidden from the user. This time, the Client designer's choice.

This forms the basic loop a client performs: get the server's address form a working address that can be used to talk over Internet. connect to the server while (not finished) do: wait until there's either information from the server, or from the user. If (information from server) do parse information show to user, update local state information, etc. else {we've got a user command} parse command send to server, or deal with locally. done

6.7.2Roles of Servers A server main feature is to accept requests from clients, handle them, and send the results back to the clients. We will discuss two kinds of servers: Single-client server, and Multi-client server.

Single Client Servers These are servers that talk to a single client at a time. They need to be able to: 1. Accept connection requests from a Client. 2. Receive requests from the Client and return results. 3. Close the connection when done, or clear it if it's broken from some reason. This forms the main loop a Single-Client Server performs: bind a port on the computer, so Clients will be able to connect forever do: listen on the port for connection requests. accept an incoming connection request if (this is an authorized Client) while (connection still alive) do: receive request from client handle request send results of request, or error messages done else abort the connection done

6.7.3 Multi Client Servers These are servers that talk to a several Clients at the same time. They need to be able to: 1. Accept new connection requests from Clients. 2. Receive requests from any Client and return results. 3. Close any connection that the client wants to end. This forms the main loop a Multi-Client Server performs: bind a port on the computer, so Clients will be able to connect listen on the port for connection requests. forever do: wait for either new connection requests, or requests from existing Clients. if (this is a new connection request) accept connection if (this is an un-authorized Client) close the connection else if (this is a connection close request) close the connection else { this is a request from an existing Client connection} receive request from client handle request send results of request, or error messages done

Chapter 7

TESTING & IMPLEMENTATION

7. TESTING AND IMPLEMENTATION

The main purpose of testing is to identify and correct errors in the candidate system. Testing is the last phase before the final software is delivered. It has enormous responsibility of detecting any type of error that may occur in the software. The unreliability of the quality assurances activities in the early part of the development cycle which is based on human evaluation place a very high responsibility on testing. The various levels of testing are, Unit Testing system Testing

UNIT TESTING The first level of testing is unit testing. In this, different modules are tested against the specifications produced during design for the modules. Unit testing is essentially for verification of the code produced during the coding phase, and hence the goal is to test the internal logic of the modules. It is typically, done by the programmer of the module. Unit testing otherwise known as module testing and this testing ensures that each module is working satisfactory as regarded to the expected output from the module. This testing is the systematic testing for constructing the program structure, while at the same time conducting test to uncover efforts associated with the interface. Hence the emphasis is on testing interface between module. All the modules are combined and tested as a whole. This testing activity can be considered as testing the design.

SYSTEM TESTING The system Testing is designed to uncover weakness that were not found in earlier tests. The reference document for this process is the requirement document, and the goal is to see if the software meets its requirement. This testing includes forced system failure and validation of the total system as it will be implemented by the user in the operational environment. Generally, it begins with the low volumes of transactions based on live data.

IMPLEMENTATION Implementation is the process of converting the new or revised system design in to an operational one. Conversion which is a changing from one system to another is one aspects of the implementation. The other aspects are the post implementation review and software maintenance. The objective here is to put the tested system in to operation while holding costs, risks, and personnel irritation to a minimum.

Chapter 8

CONCLUSION

8. CONCLUSION

The project is fulfilled all the requirements and hope that it helps NetworkOriented programmers to better the implementation in practical. The project is very much useful for system administrators to analyze the Network bottleneck, primarily in the Client-Server model. The maintenance of the client information and the status of the file transfer are done by the server. The alternate server takes the back up of the main server and transfers the file.

The project supports the client server model by sending the signals as messages and initiates the servers working. The project is developed with network as backbone, so that it is very useful for the network administrators. Some possible future work may be to improve with Multiple Server-Client model and thus apply our project to Network applications

Chapter 9

FUTURE ENHANCEMENT

9. FUTURE ENHANCEMENT

The project supports multiple clients with the enrichment of alternate server and thus increases the efficiency of the file transfer between client and server.

The additional implementation in this project may include message transfer, bulk of files and even all the network transferring functions.

In future use the project succeeds with the multiple clients and reduces the problem of redundancy.

It fulfills all the client requirements and results in the efficient file transfer.

Chapter 10

REFERENCES

10. REFERENCE

1. Maurice J.Bach, The Design of the UNIX Operating System, Chapter 6&7, process, Prentice Hall of India Pvt. Ltd.

2. The UNIX Programming Skills by Rob Pike, Bell Laboratories, Murray Hill, New Jersey.

3. Practical UNIX Programming by Ashfaq A. Khan.

4. Advanced Programming in the UNIX Environment by W.Richard Stevens.

5. The UNIX Programming Environment by Brian W.Kernighan, Bell Laboratories, Murray Hill, New Jersey.

6. The Art of UNIX Programming by Eric S.Raymond.

7. The UNIX System Programming By Kay A. Robbins and Steven Robbins.

8. UNIX Network Programming by W.Richard Stevens.

9. UNIX for Programmers & the User by Graham Glass and King Ables.

WEB REFERENCE http://www.oreilly.com/openbook/freedom/index.html http://cm.bell-labs.com/cm/cs/who/dmr/hist.html http://www.maclab.cs.uchicago.edu/tutorials/unix tutorial/unix.pdf

CHAPTER 11

APPENDIX

11. APPENDIX SIGN.C #include<stdio.h> #include<sys/socket.h> #include<sys/types.h> #include<netinet/in.h> #include<string.h> #include<stdlib.h> #include<sys/ipc.h> #include<sys/shm.h> #include <signal.h> #include <unistd.h> int pa[2],s2,ns[20],i; char st[2],ch1[2]; /* I need call a sub function and pass the value in my_addr to the subfunction, which same structure but different name*/ struct sockaddr_in my_addr; struct sockaddr_in cli_addr,their_addr; struct pi { int h; int d; char m; char file[20]; char mess[50]; }h1; void sig() /* signal handler*/ /*structure for writing and reading pipes*/ /* signal name macros, and the kill() prototype */ /* standard unix functions, like getpid() */ /* common system V IPC structures. */ /* various type definitions, like pid_t */ /* standard I/O functions */

{ ch1[0]='b'; printf("signal\n"); read(pa[0],&h1,sizeof(h1)); printf("%s %d\n",h1.mess,h1.h); s2=send(h1.h,ch1,2,0); printf("%d\n",s2); s2=send(h1.h,h1.mess,sizeof(h1.mess),0); printf("%d\n",s2); signal(3,sig); } pipe(pa); /*pipe created*/

mys=socket(AF_INET,SOCK_STREAM,0); my_addr.sin_family=AF_INET; my_addr.sin_port=htons(4350); my_addr.sin_addr.s_addr=inet_addr("127.0.0.5"); bind(mys,(struct sockaddr *)&(my_addr),sizeof(my_addr)); listen(mys,5); ss=sizeof(cli_addr); signal(3,sig); /*to handle signals from child processes*/ i=1; if(fork()==0) { printf("enter the port no"); scanf("%d",&port); mys1=socket(AF_INET,SOCK_STREAM,0); bzero(&(their_addr),sizeof(their_addr)); their_addr.sin_family=AF_INET; their_addr.sin_port=htons(port); their_addr.sin_addr.s_addr=inet_addr("127.0.0.2");

if(connect(mys1,(struct sockaddr *)&(their_addr),sizeof(their_addr))==-1) { perror("not connected\n"); exit(0); } if(ch1[0]=='f') { recv(mys1,str2,sizeof(str2),0); f2=fopen("clilist1.txt","w"); while(strcmp(str2,"fileover")!=0) { fwrite(str2,1,sizeof(str2),f2); recv(mys1,str2,sizeof(str2),0); } if(ch1[0]=='c') { f2=fopen("status.txt","w"); printf("%d\n",read(mys1,&h1,sizeof(struct pi))); while(strcmp(h1.mess,"statusover")!=0) { printf("%c\n",h1.m); if(h1.d) printf("%d\n",h1.d); fwrite(&h1,1,sizeof(struct pi),f2); read(mys1,&h1,sizeof(struct pi)); } if(fork()==0) /*client handler--clild process*/

{ if(strstr(name,"child")=='\0') { strcpy(chumma,name); strcat(name,"child"); } f2=fopen("clilist1.txt","r"); while(!feof(f2)) { ch=fgetc(f2); if(ch=='\n') { fname1[k]='\0'; f++;

inc++; if(!strcmp(fname1,name)) { flag1=1; k=0; break; if(!strcmp(str,"exit")) { ch2[0]='b'; send(z1,ch2,2,0); send(z1,str,sizeof(str),0); exit(0); } while(str[j++]!='@');/*parse the message to find the destination client name*/ k=0; while(str[j]!='@') dname[k++]=str[j++]; dname[k]='\0';k=0; printf("%s\n",dname); strcat(dname,"child"); f2=fopen("clilist1.txt","r"); while(!feof(f2)) {printf("%s\n","readfile"); ch=fgetc(f2); if(ch=='\n') { fname1[k]='\0'; f++; inc++; if(!strcmp(fname1,dname)) {printf("%s\n","found"); flag1=1; k=0; break; } write(pa[1],&h1,sizeof(h1)); /*writing into pipe the client no*/ /*client exits*/

kill(getppid(),3);/*signal to the parent to send the message to destination*/ flag1=0; inc=-1; }

CLIENT.C #include<stdio.h> */ #include<sys/socket.h> #include<sys/types.h> #include<sys/ipc.h> #include <signal.h> #include <unistd.h> #include<fcntl.h> #include<sys/sem.h> struct sockaddr_in theiraddr; FILE *f1; int mys,pid,semid,retval,retval1,port,s1,sercnt=0,p=0; char st[2],str[50],name[20],name1[20],aut[5],ch[2],ch1[2],fname[20],dname[20],fmess[ 50]; void associate(); void connection(); void new() { mys=socket(AF_INET,SOCK_STREAM,0); bzero(&theiraddr,sizeof(theiraddr)); theiraddr.sin_family=AF_INET; theiraddr.sin_port=htons(4350); theiraddr.sin_addr.s_addr=inet_addr("127.0.0.5"); if(connect(mys,(struct sockaddr*)&theiraddr,sizeof(theiraddr))==-1) recv(mys,name,sizeof(name),0); /* various type definitions, like pid_t /* common system V IPC structures. */ /* signal name macros, and the kill() prototype */ /* standard unix functions, like getpid() */ */ /* standard I/O functions

if(p==1) { strcat(name1,"child"); send(mys,name1,sizeof(name1),0); } else send(mys,name1,sizeof(name1),0); signal(5,new); } main() { semid=semget(0x20,1,0666|IPC_CREAT); signal(5,new); associate(); } void associate() { mys=socket(AF_INET,SOCK_STREAM,0); bzero(&theiraddr,sizeof(theiraddr)); theiraddr.sin_family=AF_INET; theiraddr.sin_port=htons(port); theiraddr.sin_addr.s_addr=inet_addr("127.0.0.2"); connection(); } void connection() { q:if(connect(mys,(struct sockaddr*)&theiraddr,sizeof(theiraddr))==-1) { mys=socket(AF_INET,SOCK_STREAM,0); bzero(&theiraddr,sizeof(theiraddr)); theiraddr.sin_family=AF_INET; theiraddr.sin_port=htons(4350); theiraddr.sin_addr.s_addr=inet_addr("127.0.0.5"); goto q; } else { while(1) { if(sercnt==0) { printf("enter ur name\n"); scanf("%s",name); send(mys,"new",sizeof("new"),0);

recv(mys,name1,sizeof(name1),0); if(ntohs(theiraddr.sin_port)==4000) strcat(name,"child"); send(mys,name,sizeof(name),0); strcpy(name1,name); } recv(mys,aut,sizeof(aut),0); printf("%s\n",aut); if(!strcmp(aut,"ac")) break; else continue; } pid=fork(); if(pid!=0) { while(1) { semctl(semid,0,SETVAL,1); while(semctl(semid,0,GETVAL,0)!=0); semctl(semid,0,SETVAL,1); while(semctl(semid,0,GETVAL,0)!=0); if(s1==0) { perror("Connect to alternate server\n"); kill(getppid(),5); new(); } if(ch1[0]=='a') { while(semctl(semid,0,GETVAL,0)!=1); semctl(semid,0,SETVAL,0); while(semctl(semid,0,GETVAL,0)!=1); f1=fopen(dname,"w"); strcpy(fname,"\0"); s1=recv(mys,fmess,sizeof(fmess),0); while(strcmp(fmess,"fileover")!=0) }

ALTER.C #include<stdio.h> */ #include <signal.h> #include <unistd.h> #include<sys/sem.h> #include<sys/time.h> int pa[2],s2,ns[20],i,x,cnt,fcnt=0,x1,semid; char ch1[2],c,name[20],g; struct sockaddr_in my_addr; struct sockaddr_in cli_addr; struct itimerval value; struct itimerval ovalue; void sig1() /*structure for writing and reading pipes*/ { kill(0,2); signal(SIGALRM,sig1); } struct pi { int h; int d; char m; char file[20]; char mess[50]; }h1; void al() { ch1[0]='c'; send(ns[1],ch1,2,0); while(cnt!=i-2) /* signal name macros, and the kill() prototype */ /* standard unix functions, like getpid() */ /* standard I/O functions

{ read(pa[0],&h1,sizeof(h1)); cnt++; } strcpy(h1.mess,"statusover"); write(ns[1],&h1,sizeof(struct pi)); semctl(semid,0,SETVAL,0); cnt=0; signal(2,al); } void si() { if(i!=1) { if(g==1) h1.d=x1; else h1.d=0; h1.h=i; h1.m=c; strcpy(h1.mess,name); } void sig() { ch1[0]='b'; printf("signal\n"); read(pa[0],&h1,sizeof(h1)); printf("%s %d\n",h1.mess,ns[h1.h]); s2=send(ns[h1.h],ch1,2,0); s2=send(ns[h1.h],h1.mess,sizeof(h1.mess),0); } main() { setpgrp(); strcpy(h1.file,"empty"); semid=semget(0x30,1,0666|IPC_CREAT); int mys,ss,sl,j=0,k=0,flag=0,port,f=0,inc=0,flag1=0,z; char str[50],ft[20],fmess[50]="\0",dname[50],mess[50],fname1[20],ch,str1[20],ch2[2],a lt[20]; FILE *f1,*f2,*f3; /* signal handler*/

pipe(pa);

/*pipe created*/

printf("enter the port\n"); scanf("%d",&port); mys=socket(AF_INET,SOCK_STREAM,0); bzero(&(my_addr),sizeof(my_addr)); my_addr.sin_family=AF_INET; my_addr.sin_port=htons(port); my_addr.sin_addr.s_addr=inet_addr("127.0.0.2"); bind(mys,(struct sockaddr *)&(my_addr),sizeof(my_addr)); listen(mys,5); printf("%s\n","binded"); ss=sizeof(cli_addr); value.it_interval.tv_sec=25; value.it_value.tv_sec=25; ovalue.it_value.tv_sec=0; signal(3,sig); /*to handle signals from child processes*/

signal(SIGALRM,sig1); signal(2,al); setitimer(ITIMER_REAL,(const struct itimerval*)&value,(struct itimerval*)&ovalue); while(1) printf("%d\n",ns[i]); z=ns[i]; if(i!=1) { while(1) { recv(z,str1,sizeof(str1),0); send(z,str1,sizeof(str1),0); recv(z,str1,sizeof(str1),0); f1=fopen("clilist.txt","r"); if(flag==1) { send(z,"al",5,0); } else { send(z,"ac",5,0); strcpy(name,str1); /*name already exists*/ /*name authenticated*/ /*to check for name validity*/

f1=fopen("clilist.txt","a"); fputs(str1,f1); fputc('\n',f1); if(fork()==0) { fcnt++; signal(2,si); c='n'; while(1) { fcnt=0; while(!feof(f3)) { if((fcnt%20)==0) { x1=fcnt; g=1; semctl(semid,0,SETVAL,1); kill(getppid(),SIGALRM); } if(!strcmp(str,"exit")) { ch2[0]='b'; send(z,ch2,2,0); send(z,str,sizeof(str),0); exit(0);} while(str[j++]!='@');/*parse the message to find the destination clientname*/ k=0; while(str[j]!='@') { dname[k++]=str[j++]; } dname[k]='\0'; k=0; f2=fopen("clilist.txt","r"); write(pa[1],&h1,sizeof(h1)); /*writing into pipe the client no*/ kill(getppid(),3);/*signal to the parent to send the message to destination*/ } /*client exits*/ /*client handler--clild process*/

11.2.SCREEN SHOTS