Upload
kunal-sapra
View
18
Download
1
Tags:
Embed Size (px)
Citation preview
ITERATIVE SERVER
Summer Internship Project Report
Submitted in partial fulfillment of the requirements for the degree of
Bachelor of Technology (B.Tech)
By
Srishti Agarwal
IT/08/652
July 2010
SHRI BALWANT INSTITUTE OF TECHNOLOGYApproved by AICTE, Min of HRD, Govt of India & DTE, Govt of Haryana
Affiliated to MD University, RohtakMeerut Road (Pallri), Near DPS, Sonepat-131001, Haryana
CERTIFICATE
This is to certify that the Project titled ITERATIVE SERVER and submitted by
SRISHTI AGARWAL having Roll No IT/08/652 for the partial fulfillment of the
requirements for the degree of Bachelor of Technology/Engineering (B.Tech/ B.E.),
embodies the bonafide work done by him/her under my supervision.
__________________________
Signature of the Supervisor
Place: ____________________
Date: ____________________
Acknowledgement
This report gives the details of the project work done at the end of IV/ VI
semester during the summer vacation for partial fulfillment of the
requirements for the degree of Bachelor of Technology/Engineering
(B.Tech/ B.E.), under the Supervision of AMIT KAUSHIK.
I am very grateful to my supervisor AMIT KAUSHIK for his help and able
guidance for the project. I am very thankful to my Institute, for providing me
resources and facilities to help in the project.
____________________ Signature of the Student
Name: SRISHTI AGARWAL
Date: 12th AUG,2010
Table of Contents
1 Introduction..................................................................................................................5
2 Feasibility Report.........................................................................................................6
3 Requirement Specification.........................................................................................17
4 Design Specification..................................................................................................24
5 Conclusion.................................................................................................................25
6 Checklist....................................................................................................................27
1 Introduction
The purpose of our project is to make a concurrent server. Right now we have developed an Iterative Server. A concurrent server is a server that will serve many clients request at a time without making any client to wait. In case of iterative server there is a problem that when a client is accessing his request through a server than another client cannot access that server. The Concurrent server will help to make our application distributive. It will also help to develop concurrency in our application and enhance Synchronization.
2 Feasibility Report
GENERAL INFORMATION
Purpose
The feasibility study will support the detailed planning and reduce the research time.The purpose of the feasibility study is to identify that, if we are unsure whether our project will deliver the outcome we want, then a Project Feasibility Study will help gain that clarity. The outcome of the FS is a confirmed solution for implementation.
Scope
The FS must provide sufficient information to explore the concept of server and must meet all its requirements.
The project to be made must have the scope for expanding or scope for switching to new technology later if needed in ease. (e.g. Switching from ITERATIVE to CONCURRENT SERVER)
The major scope of the project its multithreaded and distributive nature.
System Overview
We have an application using ITERATIVE SERVER in which the client communicates with the server to retrieve the requests made by it. We have used the concept of IPC’s to communicate the server and the client.
The teachers from HCL INFOSYSTEMS guided us throughout the project.
The name of our system is ITERATIVE SERVER in which we used the C with LINUX operating system.
System category Major application: For the security purpose there is the
password security provided with the application wherein only the authenticated user can perform the functions provided by the server.
General support system: the general network support is provided through the IPC’s in which we have made use of the PIPES.
This project’s status is under development to make it enhanced concurrent server.
We have worked on the LINUX system environment. LINUX is a portable operating system. It is multitasking, multi-user, multithreaded, multiprocessor and multiplatform.
Project References
Books:
Beginning Linux Programming, Second Edition
By Richard Stones and Neil Matthew
publisher: Wrox Press
UNIX Network Programming Volume 2, Second Edition: The Sockets Networking
API
By W. Richard Stevens
Publisher: Addison Wesley
Websites:
www.google.com
www.yahoo.com
Acronyms and Abbreviations
HCL – Hindustan Computers Limited
FS – Feasibility Study
IPC – Inter Process Communication
Points of Contact
Information
Reference Email addresses:
Coordination
Various organizations that are involved for the project are:
HCL INFOSYSTEMS: provided the guidance for implementation of the
project.
SBIT Management: provided us the platform for the project, and faculty of
SBIT performed time to time feedback sessions. Each member of the group
was involved in the making of project with complete coordination.
Under the guidance of HCL trainers we tried to build up the project with
coordination. The project is divided into several modules and completed by
each member of the group. The specific schedule was provided by the HCL
team, based on which our project explored.
MANAGEMENT SUMMARY
Environment
Organizations Involved
There are no project sponsors.
The developers of the project are Group Members only.
The users may include: server administrators and application developers.
Input/ Output
PC with 5 GB hard-disk and 256 MB RAM.
Linux Red Hat server 9.0
Processing
LINUX Red Hat OS
gcc Compiler
Makefile: for compilation
Error handling mechanism
Header file: #include<curses.h>
#include<utilfcns.h>
Security
The system security requirements include:
The system username and password must be authenticated so that the documents are not accessible to the outside users.
Memory management should be ensured.
Back up files are to be taken in case if any mishappening occur.
.
System Interaction
Till now we have worked on iterative server in which interaction between the single client at one time and the server is carried out through IPC (PIPES). But for the multiple clients interaction with the server, concept of forking and multithreaded will be implemented.
Physical Environment
A distributive and multithreaded environment will be used further for
implicating concurrent server.
Current Functional Procedures
The basic data flow is occurring between the client and the server through the IPC (interprocess communication).Besides this for making server
responding to the multiple clients at one time, concept of forking to switch the server from iterative to concurrent, and concept of multiprocessing and multithreaded will be implemented.
The process is being manual till now involving six to seven developers
working together.
Functional Objectives
Basic functional objectives of the project is:
Make server to respond to client at a time.
Enhancing reliability and performance of multi threaded program.
Transforming it to high performance server.
Adding scalable server functionality
Performance Objectives
To complete the project till the prescribed date. To ensure the project free from any risk failure. To ensure project complete its scope and its future enhancement.
Assumptions and Constraints
Till now our application follows the concept of iterative server where no multiple clients are able to access the server at the same time (as in echo server). But later its operational life can be improved by implementing concurrency with multithreading where multiple clients have the access to the server.
The input and output requirements may include:
PC with 5 GB hard-disk and 1 GB RAM.
LINUX Red Hat server
And the processing requirements may include:
gcc Compiler
Makefile: for compilation
Error handling mechanism
There are no such Hardware or Software changes that can take place in our system.
The Operating Environment used in our project is LINUX which is multithreaded, multi-user, multiprocessing and multiplatform
Methodology
The methodology for designing concurrent server is as accordance to the
following modules:
Module 1: Client Side Application: It provides a front end to the user to send
the request.
Module 2: Server Side Application: It includes creating files that contains
the data to satisfy the sender’s request.
Module 3: Multi threaded Server: In this we made use of IPC’s (pipe) for
the interconnectivity of interface with the files.
Evaluation Criteria
Man power used
User friendly approach
Development time
Ensure security.
Provides attractive functionality.
Recommendation
As we have to make the project completely distributive as a multithreaded concurrent server so it may take few more months.
Since it is iterative and can serve only single client at one time, this can be considered as a risk that can be tolerated.
PROPOSED SYSTEM
Description of Proposed System
The proposed system has the concept of C graphics and curses, implied on user interface.
To ensure user identification, validation of user id and password is done.
Through the user interface, multiple clients can send their request.
Improvements
First of all the very first improvement undergoes on project is to form it concurrent server from the iterative server.
Later on, it will be switch to enhanced concurrent server.
Improvements in graphics will always be there to make it more attractive.
Time and Resource Costs
The resource cost was not involved with the project as we worked on the specified environment.
The activity of the software development is done in three modules. These modules are distributed among the team members. The iterative server was developed in 6 weeks with 7 members in a group. Each module of the project is handled by two members of the group.
Currently, we are focusing on the iterative server which is being assisted by the group members.
The PC and software of LINUX used was up to date and does not require any maintenance. So no time cost for the procurement of equipment and software.
Impacts
Equipment Impacts
No equipment requirements are needed in case of the project development.
For making it distributive in nature, more PC’s can be used.
Software Impacts
The linux operating system must have ncurses library in it, besides that no
major software change is required.
Organizational Impacts
The organization will remain same throughout the development of the project. We will be assisted throughout by the HCL INFOSYSTEMS ltd and SBIT. We have not yet encountered any change need in the organization.
Operational Impacts
The effects on operations, such as:
The User operating procedures will make the project concurrent which is shared by all clients making it user friendly.
The Operating center procedures will benefit the management and developers.
The Operating center/user relationship is improving due to more communication.
Developmental Impacts
Describe the developmental impacts, such as:
The activities like: SRS, DFD’s, Specific activities to be performed by the user in support of development of the system.
Computer processing resources such as PC’s are required during the testing of the new system, and for testing distributive architecture.
Site or Facility Impacts
For distributive architecture, more number of PC’s are needed.
Security and Privacy Impacts
User authentication is provided by validating password. Memory efficient usage is ensured.
Rationale for Recommendations
The system describes us the functionality of the server to satisfy multiple clients, so that each client get the equal session and to satisfy the multiple clients request in such a way, that no client need to wait for long to get the before request completed.
Alternative System
Description of [Alternative System Name]
We are trying to develop the multithreaded enhanced concurrent server which is highly distributive and offer multiple client communication.
3 Requirement Specification
Introduction
Document Conventions
The format of this SRS is simple. The indentation is used on general topics and specific points of interest.
No other conventions were followed while writing this SRS.
Only following points are taken into consideration:
Headings are written in ‘Times New Roman’ with 14 font size in BOLD.
The details are written in ‘Times New Roman’ with 12 font size. At necessary points required documentation is provided.
This SRS is designed to acknowledge all the group members with the whole project so that they come to know about project details and recommend further changes in project if needed by:
Developers: As different modules of a project are developed by different members of the team. So to have knowledge of other modules of the project SRS is designed. It will certainly help an individual member of a team to know about the whole modules of the project.
Project Managers: Members who are going to manage this project must know about the project that’s why this SRS is designed. So that the members can manage the project according to its design.
Users: Through this SRS the user will come to know about the benefits of the project and how to gain full performance from the project.
Documentation writers: Different modules are designed by different members, so the different logics are gathered together to develop a software/project. This SRS will help in case if there is an entry of a new member in the project. Through this documentation one can understand the procedure and the logic of the project.
References www.google.com
www.yahoo.com
Overall Description
Product Perspective
Till now we are working on three modules of our project. They Modules are:
1. Module 1:
In module 1, we have the client side application i.e. the front end of our project which is directly accessible by the user.
2. Module 2:
In module 2, we have the File (Backend) system application and established its connection with the files.
3. Module 3:
In module 3, we have Multithreaded server establishing the connection between the client and the server using IPC.Iterative server is the first version of concurrent server, following section gives the brief knowledge of server working. Iterative server is one that serves a single request at a time as shown in the diagram:
WORKING CLIENT WAITING CLIENT
A SIMPLE DIAGRAM OF ITERATIVE SERVER
In future this iterative server is changed in the concurrent server by including the concept of multithread. There are different files included to develop an iterative server. A systematic diagram of joining these files is shown here:
User Classes and Characteristics
This APPLICATION can be used by any user. It can also be installed in any personal computer, but as the main concern is with the server than its users are basically technical expertise or in educational level it is also helpful.
Operating Environment
Hardware Platform: There is a need of PC with 512 MB RAM. Operating system: Linux Red Hat with 9.0 version Software Components: No other software component.
Design and Implementation Constraints
Various design and implementation constraints are:
Interface: user requires interface for accessing the services of the server. The detail concerning the request is being sent over here.
IPC: IPC (pipe or socket) is responsible for communication between the client and the server. Client sending the request to the server is carried by the IPC.
Server: the server is a program which consists of services that are accessed by the client. If the server does not provide the services then the processing cannot be handled. Server accepts the request of the client and use files to formulate a response.
Hardware: As there is a designing of concurrent server so you must have a separate system. This can create a problem in testing if you have so many systems attach with any other single server.
Memory Requirements: There is need of a large amount memory so that the designed server can work properly.
Security: No security method is provided to it but it will be implemented as soon as possible.
To move towards the next three modules, design techniques adopted are:
Multi-processing and multi-threading is implemented Make server to respond to multiple clients at one time. Utilizing multiprocessors effectively. Enhancing reliability and performance of multi threaded program. Transforming it to high performance server.
External Interface Requirements
User Interfaces
In the client side there is a need of interface through which the user can interact. The whole interface is designed with the help of graphics in Linux. Different type of windows formations is there, some window description is given below:
Welcome Screen: when the user runs the client the first screen is welcome screen. In which the two buttons are provided, one of Sign In and other is Register Now button. On clicking either button you will face other windows that are Log-in window and register window respectively.
Login Screen: This is where the user has a specific Username and Password so that they can gain access to the database. If the password and username is correct then user can continue else not.
Registration Screen: If user is new to the server then he can register his login using registration screen where he needs to enter the user id and password with some other user details.
Hardware Interfaces
In the hardware interface there is description of mouse implementation and keypad implementation:
Mouse Implementation: To select the various options provided, at some places user has to perform the selection through the mouse. In this the concept of mouse is introduced.
Keypad Implementation: Some other operations are performed through pressing key described in it present on the keyboard.
Sound Implementation: In future the concept of sound has to be implemented in it. So through speaker one can hear the voice also.
Software Interfaces
Files: In this the record is stored.
Operating System: This project will work on Linux Red Hat version 9.0.
Header Files Used: Some of the header files used are described below:
# include<stdio.h> # include<stdlib.h> #include<curses.h> #include<unistd.h>
Communications Interfaces
The system uses pipes connection to communicate with the server.
Safety Requirements
Linux visualization can be handled by setting up the resolution.
To ensure the safety from unauthorized access, user must first login, and after validation of password get confirmed.
Regarding concurrent server proper memory utilization will be done
The product is designed in Linux, so one must load Linux before running the product. The user have to be very much careful while installing the Linux as if it doesn’t installed correctly it can corrupt
one’s window. It is advisable to use particular software while installing the Linux and make window and Linux run separately.
Software Quality Attributes
Adaptability: The project is adaptable; it works according to the user instruction. The user with small change (with the concern of technical expertise) can make it work according to his/her will.
Availability: This project is developed for knowledge in the six weeks training. So its availability cannot be defined now.
Correctness: The correctness of the data stored in files depends on the user.
Maintainability: The maintainability of the project is easy.
Usability: This is an iterative server and it is going to be change in concurrent server after doing some changes in the server file. So it can be used anywhere.
Portability: This project can be run on Linux at any system where Linux is installed.
4 Design Specification
Introduction
This is the template for the specification of software designs. I have tried to provide guidelines for the contents of various sections of the document. A complete Software Design Specification meets the following criteria:
It should be able to serve as training material for new project members, providing them enough information about the project implementation, so that they are able to understand how the project should actually work.
It needs to be as detailed as possible, but should not be imposing much burden on the designers that it becomes difficult to create or maintain.
The sections in this document are concerned only with the design of the Iterative Server.
Intended Audience
Developers: As different modules of a project are developed by different members of the team. So to have knowledge of other modules of the project SRS is designed. It will certainly help an individual member of a team to know about the whole modules of the project.
Project Managers: Members who are going to manage this project must know about the project that’s why this SRS is designed. So that the members can manage the project according to its design.
Marketing Staff: What the developed software/project can do, what was its need, how it can be helpful to the users, all this information is provided to the marketing staff through this SRS. Through that a good marketing can be provided to the project and its marketing price will be good.
Users: Through this SRS the user will come to know about the benefits of the project and how to gain full performance from the project.
Documentation writers: Different modules are designed by different members, so the different logics are gathered together to develop a software/project. This SRS will help in case if there is an entry of a new member in the project. Through this documentation one can understand the procedure and the logic of the project.
Various design and implementation constraints are:
Interface: user requires interface for accessing the services of the server. The detail concerning the request is being sent over here.
IPC: IPC (pipe or socket) is responsible for communication between the client and the server. Client sending the request to the server is carried by the IPC.
Server: the server is a program which consists of services that are accessed by the client. If the server does not provide the services then the processing cannot be handled. Server accepts the request of the client and use files to formulate a response.
Goals and Guidelines
Goals, guidelines, principles, or priorities which dominate or embody the design of the Iterative Server are:
Providing a user friendly interface to the user.
A user friendly front end is provided to deal with the end user with impressive colors and eye catchy graphical effects.
Providing a server that can serve to multiclient’s request.
An Inter Process Communication is provided by PIPES to facilitate response to multiclient’s request.
Server connects easily with the Files that consist of data to satisfy client’s request.
Development Methods
Various development methods adopted to design the server are:
Graphics are implemented using ncurses.
System low level functions used are close, open, read, write.
Inter Process Communication is done by using Pipes or Sockets.
Files are created using File Handling in C language.
Architectural Strategies
Decisions and/or strategies that affect the overall organization of the system and its higher-level structures are:
Programming language: C
Backend: Files
Libraries use: ncurses, stdio, stdlib, unistd, utilfcns,
Reuse of existing software components to implement various parts/features of the system
Future plans for extending the Iterative Server to Concurrent Server.
Provides a user friendly interface.
Subsystem Architecture
All the three modules are interrelated with each other in order to get multiclient’s request and get their respective response from the server.
At the user interface the user login and registration are displayed on the screen.All these details get copied into the structure which further get passed through the PIPES or SOCKETS to the server side. At the server side server interacts with the file from which it satisfies the clients request and send the respective response through the IPC’s again.
Policies and Tactics
The design policies and/or tactics adopted to design the server are:
Compiler- gcc compiler, Makefile is used to compile the whole application.
Coding guidelines and conventions: comments and documentation is provided wherever needed
Plans for testing the project: To check whether the request is being satisfied by the server or not.
Plans for maintaining the project: Providing the appropriate commenting and documentation.
Interfaces for end-users: Providing a user friendly user interface with attractive graphical effects.
Hierarchical organization of the source code into its physical components :
Mainly five files have been formed linked with each other as follows:
User interface
Client interface
IPC(pipes) or IPC(client socket and server socket)
Server
Files
Compilation-gcc compiler, Makefile concept has been used to compile the application.
Detailed System DesignThe detailed system design describes the detailed discussion that how the three modules being divided into the subcomponents to get the desired functionality
Classification
Module1: Client side application
Basically this component is classified into the subcomponents as :
Including the color schemes. Implementing the keypad functions. Giving different graphics effect. Graphical screens are used to provide functionality to the basic application with
backend. Required header file is formed.
Module2: File application: Backend.
fopen: for opening the file
fclose: for closing the file.
fwrite: for writing to the file
fread: for reading from the file
fprintf: for printing on the file
fscanf: for taking input from the keyboard.
Module3: Multithreaded Server
This component is divided into subcomponent as:
Formation of clien.c file
Inter process communication(pipe):In order to connect the client and the server the pipe needs to get opened at server side with RDONLY mode. Then the same pipe needs to be open at WRONLY mode to send the request from the client to the server. Then to send the respective response an another pipe get opened into WRONLY mode from the server side which then get read by opening at RDONLY mode from the clients side.
Implementation of socket programming: Two files will be formed as an Inter process communication.
Definition
User interface:
The user interface basically provides the front end to the user with welcome window, registration window and login window.
Client interface:
The client interface basically provides the flow towards the Inter process communication to send the request to the server and thereby get the response in turn.
IPC(INTERPROCESS COMMUNICATION):
IPC(THROUGH PIPES OE SOCKETS) are used for communication in between the client and server, so that multi client can send their request and get their responses.
Server:
Server basically processes the clients request by interacting with the file by the help of file handling.
File:
File basically contains all the data which are retrieved by the server to get the response of the clients request.
Responsibilities
1. Client sends request to the server.
2. Server receives this request with the help of pipes and send request to file.
3. File decides whether the user can communicate with the server or not.
4. If file accepts the request then server sends this response using pipe and client can login to the next screen.
4.1 8.4 ConstraintsSome of the constraints are that to interact with front end, the end user needs to have knowledge of operating keyboard.
8.5 CompositionThe project basically comprises of following components:
user interface: Front end to the user
IPC- Inter Process Communication(pipes or sockets)
Server- It processes the request and fulfill it by giving up the required responses.
File : It stores the data.
DFD.
The DFD of the project is:
User
interface
User
interface
Client Server
File Handling
Write Read
Read Write
Files
Source Code Details
SLOC: Source Lines of Code. Use the free software sloc to calculate the SLOC
S.No Filename SLOC
1. ncurses.h Itt Window and graphics application. It is also used for the colour manipulation of the text user application
2. stldib.h It includes function for involving memory allocation and process control.
Process control has further two functions of abort and exit.
3.
4.
stdio.h
unistd.h
Provides functions for performing input output operation
It is used for pipes
Following are the details of different source codes that are used for making the project.
1. File for user interface: vi final.c
2 file for client side : vi clien.c
3. File for server side: vi serve.c
4. File for our header : vi myheader.h
5. File for file handling: vi rfile.c
6. File for all the header files used: vi shead.h
7. File for compiling user interface and client side: vi makefile
8. File for compiling file and server side: vi Makefile
vi final.c
#include<stdio.h>
#include<ncurses.h>
#include"utilfcns.h"
#include<string.h>
#include"myheader.h"
#define PW_LEN 25
#define NAME_LEN 256
#include <stdlib.h>
void wind();
void chat();
void w();
lg cc;
int v=0;
WINDOW *win[10];
main()
{
char name[NAME_LEN];
char password[PW_LEN];
char c;
mmask_t mask;
MEVENT event;
int ch,p;
int stat=0;
char pass[5];
int i=0;
initscr();
echo();
clear();
cbreak();
if(has_colors())
{
start_color();
init_pair(1,COLOR_BLACK,COLOR_MAGENTA);
init_pair(2,COLOR_GREEN,COLOR_BLACK);
init_pair(3,COLOR_RED,COLOR_YELLOW);
init_pair(6,COLOR_BLUE,COLOR_GREEN);
init_pair(4,COLOR_WHITE,COLOR_BLUE);
init_pair(5,COLOR_RED,COLOR_BLACK);
init_pair(7,COLOR_RED,COLOR_WHITE);
init_pair(8,COLOR_YELLOW,COLOR_BLACK);
}
mvaddstr(12,40,"********WELCOME TO SERVER********");
bkgd(COLOR_PAIR(5));
bkgdset(COLOR_PAIR(5));
refresh();
sleep(2);
win[8]=newwin(3,17,32,65);
wbkgd(win[8],COLOR_PAIR(7));
wbkgdset(win[8],COLOR_PAIR(7));
box(win[8],ACS_VLINE,ACS_HLINE);
mvwprintw(win[8],1,1,"%s","SIGN IN");
wrefresh(win[8]);
refresh();
win[3]=newwin(3,17,32,24);
wbkgd(win[3],COLOR_PAIR(7));
wbkgdset(win[3],COLOR_PAIR(7));
box(win[3],ACS_VLINE,ACS_HLINE);
mvwprintw(win[3],1,1,"%s","REGISTER NOW");
wrefresh(win[3]);
refresh();
keypad(stdscr,TRUE);
keypad(win[3],TRUE);
mask = mousemask(ALL_MOUSE_EVENTS, NULL);
while(toupper((ch = getch())) != 'Q')
{
if(ch == KEY_MOUSE)
{
getmouse(&event);
if(wenclose(win[3], event.y, event.x))
{
win[5]=newwin(42,123,1,1);
wbkgd(win[5],COLOR_PAIR(8));
wbkgdset(win[5],COLOR_PAIR(8));
box(win[5],ACS_VLINE,ACS_HLINE);
wrefresh(win[5]);
wattron(win[5],A_BLINK);
wattrset(win[5],A_BLINK);
w();
mvwprintw(win[5],10,15,"FIRST NAME");
mvwprintw(win[5],14,15,"LAST NAME");
mvwprintw(win[5],18,15,"D.O.B(dd/mm/yy)");
mvwprintw(win[5],22,15,"USER ID");
mvwprintw(win[5],26,15,"PASSWORD");
mvwprintw(win[5],30,15,"LOCATION");
wrefresh(win[5]);
refresh();
mvwgetstr(win[5],10,34,cc.ffname);
mvwgetstr(win[5],14,34,cc.llname);
mvwgetstr(win[5],18,34,cc.dob);
mvwgetstr(win[5],22,34,cc.id);
wmove(win[5],26,34);
noecho();
mvwgetstr(win[5],26,34,cc.pass);
echo();
mvwgetstr(win[5],30,34,cc.loc);
wrefresh(win[5]);
client(cc);
sleep(10);
chat();
echo();
endwin();
}
else if(wenclose(win[8], event.y, event.x))
{
wind();
}
}
}
}
void wind()
{
win[1]=newwin(35,70,5,18);
wbkgd(win[1],COLOR_PAIR(4));
wbkgdset(win[1],COLOR_PAIR(4));
box(win[1],ACS_VLINE,ACS_HLINE);
wattron(win[1],A_UNDERLINE);
wattrset(win[1],A_UNDERLINE);
w();
mvwprintw(win[1],10,17,"LOGIN");
mvwprintw(win[1],12,17,"USER_NAME");
mvwprintw(win[1],15,17,"PASSWORD");
wattroff(win[1],A_UNDERLINE);
wrefresh(win[1]);
mvwgetstr(win[1],12,28,cc.name);
noecho();
mvwgetstr(win[1],15,28,cc.password);
wrefresh(win[1]);
sleep(2);
echo();
v=server(cc);
if(v==1)
{
mvwprintw(win[1],19,28,"correct login");
wrefresh(win[1]);
sleep(5);
chat();
}
else
{
mvwprintw(win[1],19,28,"incorrect username or password");
mvwprintw(win[1],22,28,"TRY AGAIN");
wrefresh(win[1]);
sleep(3);
wind();
}
}
void chat()
{
win[2]=newwin(44,125,0,0);
wbkgd(win[2],COLOR_PAIR(2));
wbkgdset(win[2],COLOR_PAIR(2));
box(win[2],ACS_BOARD,ACS_BOARD);
mvwprintw(win[2],20,30,"welcome to the chat server");
wrefresh(win[2]);
sleep(10);
endwin();
}
void w()
{
win[9]=newwin(4,30,4,90);
wbkgd(win[9],COLOR_PAIR(2));
wbkgdset(win[9],COLOR_PAIR(2));
box(win[9],ACS_VLINE,ACS_HLINE);
wrefresh(win[9]);
}
Vi clien.c#include "myheader.h"
#include"shead.h"
#include <ctype.h>
#include<ncurses.h>
WINDOW *win[10];
void client(lg cc)
{
int server_fifo_fd, client_fifo_fd;
int times_to_send;
char client_fifo[256];
#if DEBUG_TRACE
mvwprintw(win[9],1,1,"%d :- creating client fifo",getpid());
wrefresh(win[9]);
#endif
mkfifo(SERVER_FIFO_NAME,0777);
server_fifo_fd=open(SERVER_FIFO_NAME, O_WRONLY);
if (server_fifo_fd==-1)
{
fprintf(stderr,"SORRY NO SERVER\n");
exit(EXIT_FAILURE);
}
cc.st=1;
write(server_fifo_fd,&cc,sizeof(cc));
close(server_fifo_fd);
}
int server(lg cc)
{
int read_res,v;
int server_fifo_fd, client_fifo_fd;
int times_to_send;
char cf[25];
server_fifo_fd=open(SERVER_FIFO_NAME, O_WRONLY);
if (server_fifo_fd==-1)
{
fprintf(stderr,"SORRY NO SERVER\n");
exit(EXIT_FAILURE);
}
cc.st=0;
write(server_fifo_fd,&cc,sizeof(cc));
close(server_fifo_fd);
#if DEBUG_TRACE
mvwprintw(win[9],1,1,"%d :- creating client fifo",getpid());
wrefresh(win[9]);
#endif
mkfifo(CLIENT_FIFO_NAME,0777);
client_fifo_fd=open(CLIENT_FIFO_NAME,O_RDONLY);
read_res=read(client_fifo_fd,&v,4);
if(read_res>0)
{
if(v)
return(1);
else
return(0);
}
close(client_fifo_fd);
}
vi serve.c#include"myheader.h"
#include "shead.h"
#include <ctype.h>
int main()
{
int m=0;
int v;
lg cc;
int server_fifo_fd,client_fifo_fd;
int read_res;
char clf[25]={'\0'};
#if DEBUG_TRACE
printf("%d :- server starting()\n", getpid());
#endif
mkfifo(SERVER_FIFO_NAME,0777);
#if DEBUG_TRACE
printf("%d :- server fifo created\n", getpid());
#endif
server_fifo_fd=open(SERVER_FIFO_NAME,O_RDONLY);
if(server_fifo_fd==-1)
{
fprintf(stderr,"SERVER fifo failure\n", getpid());
exit(EXIT_FAILURE);
}
sleep(1);
do
{
read_res=read(server_fifo_fd,&cc,sizeof(cc));
if(read_res>0)
{
if(cc.st==1)
{
#if DEBUG_TRACE
printf("%d :- REGISTRING\n", getpid());
#endif
rite(cc);
}
else
{
#if DEBUG_TRACE
printf("%d :- LOGING\n" ,getpid());
#endif
v=reed(cc.name,cc.password);
client_fifo_fd=open(CLIENT_FIFO_NAME,O_WRONLY);
write(client_fifo_fd,&v,4);
close(client_fifo_fd);
}
}
}
while(1);
#if DEBUG_TRACE
printf("%d :- server ending()\n ", getpid());
#endif
close(server_fifo_fd);
exit(EXIT_SUCCESS);
}
vi myheader.htypedef struct log
{
char id[20],pass[20],ffname[20],llname[20],loc[20],dob[10],name[20],password[20];
int st;
}lg;
void rite(lg cc);
int reed(char *,char *);
void client(lg cc);
int server(lg cc);
void wind();
void w();
void chat();
vi rfile.c#include<stdio.h>
#include<ncurses.h>
#include "myheader.h"
#define PW_LEN 25
#define NAME_LEN 50
FILE *f;
WINDOW *win[10];
lg cc;
int stat=0;
char name[NAME_LEN];
char password[PW_LEN];
void rite(lg cc)
{
f=fopen("saap.txt","w");
fwrite(&cc,sizeof cc,1,f);
fclose(f);
}
int reed(char *name,char *password)
{
f=fopen("saap.txt","r");
stat=0;
while(fread(&cc,sizeof cc,1,f)==1)
{
if((strcmp(name,cc.id)==0)&&(strcmp(password,cc.pass)==0))
{
stat=1;
break;
}
}
fclose(f);
return stat;
}
vi Makefileall: app
app: serve.o rfile.o
gcc -o app serve.o rfile.o -lncurses -D DEBUG_TRACE=1 -g
serve.o: serve.c myheader.h
gcc -c serve.c -lncurses -D DEBUG_TRACE=1 -g
rfile.o: rfile.c myheader.h
gcc -c rfile.c -D DEBUG_TRACE=1 -g
5 10. Output
6 Conclusion
In our six weeks summer training we have developed an Iterative Server. We will be developing a Concurrent Server in six months training. A concurrent server is a server that will serve many clients request at a time without making any client to wait. In case of iterative server there is a problem that when a client is accessing his request through a server than another client cannot access that server. The Concurrent server will help to make our application distributive.
7 ChecklistThis checklist is to be attached as the last page of the report.
This checklist is to be duly completed by the student and verified by the Programme Coordinator and HOD
1. Is the report properly spiral bound? Yes / No
2. Is the Cover page in proper format? Yes / No
3. Is the Title page in proper format? Yes / No
4. (a) Is the Certificate from the Supervisor in proper format?
(b) Has it been signed by the Supervisor?
Yes / No
Yes / No
5. (a) Is the Acknowledgement from the Student in proper format?
(b) Has it been signed by the Student?
Yes / No
7. Does the Table of Contents include page numbers?
(i). Are the Pages numbered properly?
(ii). Are the Figures numbered properly?
(iii). Are the Tables numbered properly?
(iv). Are the Captions for the Figures and Tables proper?
(v). Are the Appendices numbered properly?
Yes / No
Yes / No
Yes / No
Yes / No
Yes / No
Yes / No
8. Is the conclusion of the Report based on discussion of the work? Yes / No
9. Are References or Bibliography given in the Report?
Have the References been cited inside the text of the Report?
Is the citation of References in proper format?
Yes / No
Yes / No
Yes / No
10. A Compact Disk (CD) containing the softcopy of the Final Report (preferably in PDF format) and a Final Project Presentation in MS power point only (made to the Supervisor / Examiner has been placed in a protective jacket securely fastened to the inner back cover of the Final Report. Write the name and Roll No on
Yes / No
the CD.
Declaration by Student
I certify that I have properly verified all the items in the checklist and ensure that the report is in proper format as specified in the course handout.
Name:
Place:
Date:
Signature of the Student:
Verification by HOD
I have duly verified all the items in the checklist and ensured that the report is in proper format.
Name:
Place:
Date:
Signature of the HOD:
Verification by Programme Coordinator
I have duly verified all the items in the checklist and ensured that the report is in proper format.
Name:
Place:
Date:
Signature of the Programme Coordinator: