Alternate Server and Message Passing

8/13/2019 Alternate Server and Message Passing

http://slidepdf.com/reader/full/alternate-server-and-message-passing 1/93

ALTERNATE SERVER AND MESSAGE PASSING

A PROJECT REPORT

Submi tted by

P.BALAMURUGAN (30605104012)

G.KARTHICK (30605104023)

in parti al ful fi llment f or 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 iii

LIST OF FIGURE vi

LIST OF TABLES vii

1. INTRODUCTION 1

1.1 Server Crashing 1 1.2 Alternate Server 2

2. LITERATURE REVIEW 4

3. SYSTEM ANALYSIS 5

3.1 Existing System 5

3.2 Proposed System 5

3.3 Problem Description 6

4. SOFTWARE HARDWARE ENVIRONMENT 7

4.1 Operating System 7

4.1.1 LINUX operating system 7

4.1.2 Red Hat Linux 5.1 7

4.1.3 History of LINUX 8

4.2 About the language 9

4.2.1 UNIX operating system 9

4.2.2 UNIX environment 10

4.3 Hardware Description 10

4.4 Software Description 11



5. SYSTEM DESIGN 12

5.1 Block Diagram 12

5.2 Data Flow Diagram 15

5.3 Socket programming 17

5.3.1 Socket Creation and Naming 19

5.3.2 Connecting Stream Sockets 21

5.3.3 Datagram Sockets 22

5.3.4 Socket Options 25

5.4 Signals 26

5.4.1 Handling Signals 27

6. PROJECT DESCRIPTION 28

6.1 Main server 28

6.2 Alternate Server 29

6.3 Client 30

6.4 Structured used 30

6.4.1 Pre Defined Structure 31

6.4.2 User Defied structure 32

6.5 File handling 33

6.5.1 Function Used 34

6.6 Signals 36

6.7 Client Server Model 40

7. TESTING AND IMPLEMENTATION 46

8. CONCLUSION 49

9. REFERENCE 50

10. APPENDIX 51

10.1 Coding 51

10.2 Screen Shots 61



LIST OF FIGURES



LIST OF FIGURE

FIG NO TITLE OF FIGURE PAGE NO

5.1.1 AITERNATE SERVER AND

MESSAGE PASSING 12

5.1.2 BEFORE SERVER CRASHING 13

5.1.3 AT THE TIME OF SERVER CRASHING 14

5.2.1 DATAFLOW DIAGRAM 15

5.2.2 FAILURE OF THE MAIN SERVER 16

5.3.1(a) STATE TRANSTITION OF SERVER

STREAM SOCKET 20

5.3.1(b) STATE TRANSTITION OF CLIENT

STREAM SOCKET 22

5.3.3(a) STATE TRANSTITION OF DATAGRAM SOCKET 23

5.3.3(b) ALTERNATE STATE TRANSTITION OF

DATAGRAM SOCKET 24

5.3.4 OSI LAYER 25

vi



LIST OF TABLES



LIST OF TABLES

TABLE NO TITLE OF TABLE PAGE NO

1.1 MACRO SIGNALS

HEADER FILES 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 client‟s 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 servermaintains 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. Theservers 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 HARDWAREENVIRONMENT



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 Foundation‟sGNU 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, Torvald‟s individual effort, and many collaborators all over

the world. In addition to its use by many individual programmers; Linux has nowmade 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 numberof 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 ofcomputers 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 1970‟s, 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 you‟ve 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 you‟re familiar with

Windows or DOS, you‟ll 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 don‟t 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 : Intel Dual core 3.3 MHZ

Cache : 250 KB

Hard disk : 120 GB

Floppy drive : 1.44 MB

CD drive : 52X CD-ROM

Monitor : 17‟‟ LCD Color Monitor

RAM : 1 GB

Keyboard : Samsung

Mouse : 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.

Programming Language : UNIX



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



5.2 DATA FLOW DIAGRAM

Registration & Transaction

Fig 5.2.1 REGISTRATION AND TRANSACTION

CLIENT

DATABASE

CONNECTIN

G CLIENT

TRANSACTIO

N IN SERVERSERVER DB

Reply Data Request

Registration

Request Message



FAILURE

Fig 5.2.2 FAILURE OF THE MAIN SERVER

SIGNAL MESSAGES BY

ALTERNATE SERVER AT

PERIODIC INTERVALS BYTIME

VALIDITY BY

SIGNAL

CONTINUE

WITH

EXISTING

LOG

FILE

Signal

No

Signal

Yes

CONNECT CLIENTWITH ALTERNATE

SERVER

Server Failure

Transaction

update

message



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 UserDatagram Protocol (UDP).

A sequential packet socket

Its provides a two-way, sequenced, reliable, connection, for

datagram‟s of a fixed maximum length. The sock et 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()).

Fig 5.3.4 OSI LAYERS

Application Layer

(RPM Server

Transport Layer

(UDP)

Network Layer(IP)

Link Layer

&

Physical Layer

Application Layer

(RPM Server)

Transport Layer

(UDP)

Network Layer(IP)

Link Layer

&

Physical Layer

Transmission Line



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 thesocket 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 can‟t 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.



char sin_zero[8]; /*unused*/

};

Timer structure „ITIMERVAL‟.

This structure is contained in <sys/time.h>

struct itimerval

{ struct timeval it_interval; /*next value*/

strcut timeval it_value; /*current value*/

};

struct timeval

{ long tv_sec; /*seconds*/

long tvusec; /*microseconds*/

};



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; /*child identifies*/

int bytes; /*no. of bytes transferred*/

char m; /*identifies file transfer/message transfer */

char file[20]; /*file name of transferring file (m=‟f‟)*/

char mess[50]; /*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 */ SIGINT 2 /* interrupt */

SIGQUIT 3 /* quit */ SIGILL 4 /* illegal instruction */

SIGABRT 6 /* used by abort */ SIGKILL 9 /* hard kill */

SIGALRM 14 /* alarm clock */

SIGCONT 19 /* continue a stopped

process */

SIGCHLD 20 /* to parent on child

stop or exit */

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 signalSIGALRM 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 Network-

Oriented 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 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





http://www.maclab.cs.uchicago.edu/tutorials/unix%20tutorial/unix.pdf







CHAPTER 11

APPENDIX



11. APPENDIX

SIGN.C

#include<stdio.h> /* standard I/O functions */

#include<sys/socket.h>

#include<sys/types.h> /* various type definitions, like pid_t */

#include<netinet/in.h>

#include<string.h>

#include<stdlib.h>

#include<sys/ipc.h> /* common system V IPC structures. */

#include<sys/shm.h>

#include <signal.h> /* signal name macros, and the kill() prototype */

#include <unistd.h> /* standard unix functions, like getpid() */

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 /*structure for writing and reading pipes*/

{

int h;

int d;

char m;

char file[20];

char mess[50];

}h1;

void sig() /* signal handler*/



{ 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++;



CLIENT.C

#include<stdio.h> /* standard I/O functions

*/

#include<sys/socket.h>

#include<sys/types.h> /* various type definitions, like pid_t */

#include<sys/ipc.h> /* common system V IPC structures. */



#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()

{


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



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

{




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)

{




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



if(s1==0) { perror("Connect to alternate server\n");

kill(getppid(),5);

new(); }

if(ch1[0]=='a')

{ 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> /* standard I/O functions

*/



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



{ 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() /* signal handler*/

{ 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;



pipe(pa); /*pipe created*/

printf("enter the port\n"); scanf("%d",&port);


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"); /*to check for name validity*/

if(flag==1)

{ send(z,"al",5,0); /*name already exists*/

} else { send(z,"ac",5,0); /*name authenticated*/

strcpy(name,str1);



f1=fopen("clilist.txt","a");

fputs(str1,f1);

fputc('\n',f1);

if(fork()==0) /*client handler--clild process*/

{ fcnt++;

signal(2,si);

c='n';

while(1) {

fcnt=0;

while(!feof(f3))

{ if((fcnt%20)==0)

{ x1=fcnt; g=1;


kill(getppid(),SIGALRM);

} if(!strcmp(str,"exit")) /*client exits*/

{ 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*/

}



11.2.SCREEN SHOTS

Alternate Server and Message Passing

Documents

Transcript of Alternate Server and Message Passing