You are on page 1of 108

CHAPTER 1 Introduction and objective of the project

1.1- Background:
Nowadays vast majorities of organization have got computer networks, So that information technology can help them to grow and manage their business efficiently. Numbers of these networks are continuously increasing because the cost to create and maintain such a network has gone down tremendously. Therefore there is an urgent need to develop such software, so that this networking infrastructure can be utilized most efficiently to benefits the organization needs. Networking means an interconnected collection of autonomous computers. networking play the important role in the information technology, many organizations have a substantial number of computers in operation often located far a part. For example a company with many factories may have a computer at each location to keep track of inventories, monitor their productivity and do the local payroll. Initially each of these computers may have worked in isolation from the others, but at the some point, management may have decided to connect them to be able to extract and correlate information about the entire company. Few application software in this area are e-mail software, File Transfer Protocol, Web browser etc. Many Organization have a substantial numbers of computers in operation, often located for apart to communicate with each other in the organization they are connected through the network based on client server model. In the client server model communication generally takes the form of a request message from the client to the server asking for some work to be done. The servers then do the work and send back reply. A computer network provide a powerful communication medium among widely separated employees, using network it is easy for two or more people who live for apart to write the report together. Electronic mail or E-mail as its many fans knows it has been around for over two decades. The first E-mail system simply consisted of file transfer protocol, with the convention that the first line of each message (i.e. file) contained the recipients address. As time went on the limitation of this approach become more obvious. As experience was gained more elaborate E-mail systems were proposed. The ARPNET E-mail proposals were published as RFC 821 (transmission protocol) And RFC 822 (message format), after decade of competition-mail system based on RFC821 are widely

used. The reason for RFC 822 success is not that it is so good, but that X.400 is so poorly designed and so complex that no body could implement it well.

1.2- Objective of the Project: The objective of this project is to develop an email system which will
work within an organization. E-mail system normally consists of two sub systems: 1. The user agent: Which allow people to read and send e-mail 2. Message transfer agent: which move the messages from the source to destination. The user agents are local programs that provide a command-based, menu-based, or graphical method for interacting with the e-mail system. The message transfer agents are typically system daemons that run in the background and move email through the system. Typically e-mail systems support five basic functions as describe below: (a) Composition: Refers to the process of creating messages and answers (b) Transfer: Refers to moving messages from the originator to the recipient. (c) Reporting: Refers to telling the originator that what happened with the message? Was it delivered? Was it rejected? Was it lost? (d) Displaying: Incoming message is needed so people can read their e-mail. (e) Disposition: Concerns what the recipient does with the message after receiving it. Most systems allow users to create mail boxes to store incoming e-mail. Commands are needed to create and destroy mailboxes, inspect the contents of mailboxes, insert and delete messages from mailboxes and so on. The idea of mailing list is also available which shows a list of e-mail addresses. This is client-server based software, which gives the facility to transfer/receive through network using LAN. For this purpose it takes the services of TCP/IP. This is oriented towards iterative & connection oriented services than connectionless concurrent services which make it easier to make & understand and provides reliable services.

1.3- Scope of the project:

The aim of this project to develop software, which works as e-mail server. It will have GUI facilities for all operations required for mailing. E-mail server will provide the facility for creating a user. Maintain its incoming mail and sending it when user desires to get it Composing a mail Deleting a mail GUI feature will be available.

A graphical user interface is a system that gives a standard way to application programs exploring different objects such as menus, icons, dialog boxes, mouse a keyboard. Some of the typical example of GUI is Microsoft windows, Macintosh and X-windows.

CHAPTER 2

System Analysis
2.1- Identification of Need:
When we talk about email general question arises why should we use this email, when ordinary email transfer/receive work and others software are there. There are a lot to say in favor of this software. This software has been made to use within a organization which will save the cost to be paid to external organization for using email facility. Any number of users can be provided this email facility without adding anything to the cost. Our email server verifies the identity of the user by: Guaranteeing that data is unintentionally revealed or compromised. It keeps information about an individual form unauthorized access. Guaranteeing that network application cannot abuse system resources. It uses the GUI interface to make easy to handle.

2.2-Preliminary Investigation: I discussed with various people about the utility of this software and
everyone appreciated the idea because it is very helpful for the organizations.

2.3- Cost Estimation of the Project:


To determine the cost estimate for a this Graphics Package, we need to consider the following costs elements; 2.3.1- Hardware Cost: - Every person can bear Hardware costs for this package. Because a general PC hardware cost are require for this. 2.3.2-Facility Cost: - Facility cost may be same as facility of simple PC. 2.3.3- Operating Cost: - Operating costs of this project is same as windows based PC. Because this project works like as windows based applications/packages. So, no other requirements of operating cost. Anybody who operates the windows based applications/packages who will also operate this package.

2.3.4-Training Cost: - For operating this package training cost takes a few amount of money as well as less time. Because; now a days, all the computer operators must know to operate successfully windows based systems as well as its application soft wares/packages (e.g. Notepad, WordPad, MS-Word etc.) And this project has developed windows based environments. So, we have not trouble to locate for a good trainer as well as no more other requirements of expensing time for training. 2.3.5- Supply Cost: - There are following supply costs: a) b) c) d) Cartridge costs: - For a printer Paper costs: - For A4 size paper. Disks costs: - For 3.5 Floppy Disks or Compact Disks. Personnel Costs: - This cost may be simple because not we will ever necessity of

highly technical personnel who knows to operate windows based applications.

CHAPTER 3 Feasibility Study:


3.1- Technical Feasibility:
As TCP/IP allows to programmer to establish communication between programs and to pass data back and forth. In practice one organizational method dominates the use of TCP/IP to such an extent that almost all applications use it. The method is known as client-server paradigm and it is used in this project. We have used the iterative method that is simple than concurrent making it feasible. One of the major factors driving any production disciplines is quality in current time, quality is main mantra, and business strategies are designed around quality. Clearly developing methods that can produce high quality s/w is fundamental goal of s/w engineering. But coast increases when quality increases so one have to compromise with the quality and coast, and it is provided by our software using iterative rather than concurrent to lower the cost but doing so performance is not so lowered when it is used in the LAN environment. Software is adoptive as the client increases more than the capability of the server one can go to the server and can change the max. Limit if the memory of the server allows it and also other modification can be done easily in it.

3.2- Economical Feasibility:


To implement this software, we do not need much hardware or software. We need one server and LAN environment, which every institute/company generally has. The cost of developing this software is very less as no special software is required to develop it. Any simple database and Microsoft visual C++ was required to develop this project.

3.3- Operational Feasibility:


This test of feasibility asks if the system will work when developed and installed. Are there major barriers to implementation? Is this sufficient for the project from the management? There is no extra management required to manage this S/W, so it is operationally feasible. As an output of feasibility test, we can conclude that this project passes out three feasible tests, so it is a feasible project.

CHAPTER 4 Software Engineering Paradigm Applied


4.1- Client-Server Architecture:
4.1.1- Introduction: From the viewpoint of an application TCP/IP like most computer communication protocols, merely provides basic mechanism used to transfer data. In particular, TCP/IP allows a programmer to establish communication between to application programs and to pass data back and forth. Thus we can say that TCP/IP provides peerpeer communication. The peer applications can execute on the same machine or on different machines. Although TCP/IP specifies the details of how data posses between a pair of communicating applications, it does not dictate when or why peer application do not interact, nor does it specifies how programmers should organize such application programs in a distributed environment. In practice, one organizational method dominates the use of TCP/IP to such an extent that almost all applications use it. The method is known as client-server paradigm. In fact, client-server interaction has become so fundamental in peer-peer networking systems that it forms the basis for most computer communication. This is why we are using client-server paradigm in our project. 4.1.2- Motivation: The fundamental motivation for the client-server paradigm arises from the problem of rendezvous. To understand the problem, imagine a human trying to start two programs on separate machines and have them process. Also remember that computers operate many orders of magnitude faster than humans. After the human initiates the first program, the program begins execution on sends a message to its peer. With in a few milliseconds, it determines that the peer does not yet exist, so it emits an error message and exists. Meanwhile, the human initiates the second program. Unfortunately, when the second program starts execution, it finds that the peer has already ceased execution. Even if the two programs retry to communicate continually, they can each execute so quickly that the probability of them sending messages to one another simultaneously is low. The client-server models solves the rendezvous problem by asserting that in any pair of communicating applications, one side must start execution and wait for the other side to contact it.

The solution is important because TCP/IP does not respond to incoming communication request on its own. Because TCP/IP does not provide any mechanism that automatically create running programs when a message arrives, a program must be waiting to accept communication before any requests arrive. Thus to ensure that computers are ready to process, most system administrators arrange to have communicate programs start automatically whenever the operating system boots. Each programs runs forever, waiting for the next request to arrive for the service offers.

4.2- Gantt Chart:


Gantt charts are project control technique that can be used for several purposes, including scheduling, budgeting and resource planning. A Gantt chart is a bar chart, with each bar representing an activity. The bars are drawn against a time line. The length of each bar is proportional to the length of time planned for the activity. I estimated the number of weeks required for each of the seven tasks as follows: Analysis Design Coding Testing Write manual Implementation Maintenance 4 weeks 4 weeks 12 weeks 6 weeks 3 weeks 2 weeks 2 weeks

Activity Analysis Design coding Testing Write manual Implementation Maintenance Activity Analysis Design coding Testing Write manual Implementation Maintenance

01 _

02 _

03 _

04 _

05

06

07

08

09

10

11

12

_ _ _ _ _

13

14

15

16

17

18

19

20

21

22

23

24

_ _

_ _

_ _

_ _ _

_ _ _

_ _ _ _ _ _ _

GANTT CHART

PERT CHART:
Unlike Gantt chart, PERT can be both a cost and time management system. PERT controls time and costs during the project and also facilitates finding the right balance between completing a project on time and completing it within budget. PERT recognizes that some tasks must be completed before others can be started, and that the appropriate way to manage a project to define and control each tasks.

Week 15

TESTING

Week 1

Week 5

Week 9

Week 21

ANALYSIS

DESIGN

CODING

IMPLEMENTATION

Week 18

WRITING MANUAL

Week 23

MAINTENANCE

Week 24

FINISH

PERT CHART

CHAPTER 5 Software and Hardware Requirement Specifications


5.1- Hardware requirement:
5.1.1- Hardware specification: 1) Processor 2) RAM Pentium 128 MB minimum

3) Hard Disk Controllers Intel, PCIB Bus Master IDE Controller 4) Network Adapters Crystal Semiconductor.

5) Communication part COM 1, COM 2 6) Monitor 7) Key board 8) Mouse 9) Printer 10) 11) 12) 13) minimum. 5.1.2- LAN: IBM, standard 15color IBM, standard Keyboard (101Key) Standard PS/2 port mouse. Canon BJC-2100SP (standard) Cache memory Floppy Disk Hard Disk Monitor Adapter 32 MB. Approx. 3.5, 1.44MB.Capacity 40GB. VGA Adapter resolution 640480,16color

For any two PC to communicate they should be connected so it is necessary that institute should have LAN structure which is going to use FTP.LAN is suitable for FTP because LAN run at speed of ten 10-100mbps, have low delay (10 of microseconds) and make very few errors. Thus in process error should not be there and LAN provides it. 5.1.3- Server: Here we specify server as computer in which server program runs. Thus server should be of high processing speed and should be placed in the safe place so that no one can disturb it. Thus ones server program begin to execute, no one should disturb it. Database should be in server, and only data administrator can change. Every powerful work is done at server because it is of high processing speed. It also stores sending/receiving file of every client. Server should be highly processing speed and safely placed. All the high work is done on it, it also maintains database.

5.2- Software requirement:


5.2.1- Operating system: FTP requires one of the following operating system 1. Windows 95/98. 2. Windows NT. 3. Windows 2000. 4. Windows ME. 5.2.2- Visual C++: For providing a good GUI we are using VC++. It provides environment in which user can easily understand the working of the program. It also gives the facilities to use Windows object in the program.

5.2.3- MFC: The Microsoft foundation class library Windows is built on top of the C language Windows application-programming interface (API) to ensure long-term compatibility with the thousands of applications already written for Windows. MFC is a truly object-oriented interface designed with the following goals in mind: Significantly reduced effort for programming an application for Windows. Execution speed comparable to that of the C language API. Minimum code size overhead. Ability to call any Windows C function directly. Easier conversion of existing C application to C++. Ability to leverage from the existing base of C language Windows programming experience. True windows API for C++ that effectively uses C++ language features.

Library classes represent windows, dialog boxes, device context, common GUI objects, and other standard Windows item. These classes provide a convenient C++ member function interface to the structures in the Windows that they encapsulate.

CHAPTER 6 System Design


It uses the socket programming to implement all the features. When a client wants to send/receive email with other client, Firstly it creates a socket then tries to make a connection to a socket of the server. When this connection is established sending and receiving of email begins between the client & server. Server stores all the email send by the client with the name. So that it can further deliver the email to the other clients, who try to receive the email after establishing a connection to the server. For every client, server has to make a separate socket with IP address & port no. By which server remembers distinction between the sockets of the different clients. When a client finishes it sending or receiving the email, connection is disconnected & server again reaches to the listen mode in which it checks if any client want to connect to it or not.

6.1- Server Architecture:


6.1.1- Connection-Oriented Vs Connection-Less Services: The issue of connectivity centers on the transport protocol that a client uses to access a server. In TCP/IP protocol suit TCP/IP provides a connection-oriented transfer, by definition, connectionoriented server while those that use UDP are connection-less server. Although we apply the terminology to servers, it would be more accurate if we restricted in to application protocol, because the choice between connection-less and connection-oriented implementation depends on the application protocol. An application protocol design to be uses a connection-oriented transport service may perform incorrectly are inefficiently when using a connectionless transport protocol. To summarize: When considering the advantages and disadvantages of various server implementation strategies, the designer must remember that the application protocol used may restrict some or all the choices. 6.1.2- Concurrent Vs Iterative services:

Term iterative server is used to describe a server implementation that processes one request at a time, and the term concurrent server to describe a server that handles multiple requests at one time. The term concurrent server refers to whether the server handles multiple requests concurrently, not to whether the underlying implementation uses multiple concurrent processes. In general, concurrent servers are more difficult to design and build, and the resulting code is more complex and difficult to modify. Most programmers choose concurrent server implementations, however, because iterative servers cause unnecessary delays in distributed application and can become a performance bottleneck that affects many client applications. We can summarize: Iterative server implementations, which are easier to build and understand, may result in poor performance because they make clients wait for service. In contrast, concurrent server implementations, which are more difficult to design and build, yield better performance. Algorithm for iterative, connection-oriented server: 1. Create a Socket and bind to the well-known address for the service being offered. 2. Place the Socket in passive mode, making it ready for use by a server. the connection. 4. Repeatedly read a request from the client, formulate a response, and send a reply back to the client according to the application protocol. 5. When finished with a particular client, close the connection and return to step 3 to accept a new connection. 3. Accept the next connection request from the Socket, and obtained a new Socket for

6.2- Client Architecture:


Application that act as a clients are conceptually simpler than application that act as servers for several reasons. Because it does not explicitly concurrent iterations with multiple servers, and unlike server s/w, client s/w does not usually require sectional privilege, and also it does not need to enforce protections. Instead, client program can rely on the operating system to enforce protection automatically. 6.2.1- The TCP Client Algorithm:

A TCP client follows algorithms 2.4 to form a connection to server and communicate with it. 1. Find the IP address and protocol port number of server with which communication is desirable? 2. Allocate a Socket. 3. Specifies that the connection needs an arbitrary, unused protocol port on the local machine, and allow TCP to choose one. 4. Connect the Socket to the server. 5. Communicate with the server using the application level protocol (this usually invokes sending requests and awaiting replies). 6. Close the connection. 6.2.2- Identifying the Location of the Server: Client software can use one of the several methods to find a server IP address and protocol port number. Have the servers domain name or IP address specified as a constant when program is compiled. Require the user to identify the server when invoking the program. Obtain information about the server from the stable table (from a file or local disk). Use a separate protocol to find a server (multicast or broadcast a message to which all server respond). Allowing the user to specify a server address when invoking client s/w makes client program more general and makes it possible to change the servers location. And building client software that accept a server address as an argument makes it easy to build extended versions s/w that use others ways to find the server address (e.g. read the address from a file on disk). 6.2.3- Problems in choosing local-IP address: When forming a connection endpoint, a client much choose a local IP address as well as a local port number. For a host that attach to a one network, the choice of a local IP address is trivial. However, because gateways or multi_homed hosts have multiple IP addresses, making the choice can be difficult. In general, the difficulty in choosing in IP address arises because the correct choice depends on routing and applications seldom have access to routing information. To understand why, imagine a computer with multiple network interfaces and, therefore multiple IP addresses. Before an application

can use TCP, it must have an end point address for the connection. When TCP communicate with the foreign destination, it encapsulates each TCP segment in IP datagram and passes the datagram to the IP software. IP uses the remote destination address and its routing table to select a next hop address and a network interface that it can use to reach the next hop. Here in lies the problem: the IP source address in an out going datagram should match the IP address of the network interface over which IP routes the datagram. However, if an application chooses one of the machines IP addresses at random, it might select an address that does not match that of the interface over which IP routes the traffic. In practice, a client may appear to work even if the programmer chooses an incorrect address because packets may travel back to the client by a different route than they travel to the server. However, using an incorrect address violates the specification, makes network management difficult and confusion, and makes a program less reliable. To solve the problem, the Socket calls make it possible for an application to leave the local IP-address field unfilled and to allow TCP/IP software to choose a local IP address automatically at the time the clients connects to a server. Because choosing the correct local IP-address requires the application to interact with IP routing software, TCP client software usually leaves the local end point address unfilled, and allows TCP/IP software to select the correct local IP-address and an unused local protocol port number automatically. 6.2.4- Choosing A Local Protocol Port Number: An application needs to specify remote and local end point address for a Socket before it can be used in communication. A server operates at a well-known protocol port address, which all clients must know. However, a TCP client does not operate on a reassigned port. Instead, it must select a local protocol port number to use for its end point address. In general, the client does a not care it uses as long as 1. The port does not conflict with the ports that other processes on machine are already using and 2. Port has not been assign to a well-known service. Of course, when a client meets a local protocol port, it can choose an arbitrary port at random until it finds one the needs the criteria given above. However the Socket interface makes choosing a client port much simpler because it provides a way that the client can allow TCP to choose a local port automatically. The choice of a local port that meets the criteria listed above happens a side effect of connect call.

6.3 Screen Design: Server Dialog Box:

Client Dialog Box:


This is main dialog box where information about the project is provided. When user clicks on ON button, login dialog box is displayed.

User Authentication: Here user gives login name and password and also gives the servers address
to connect to it. After user press OK button information goes to the server. If it found correct user connects to the server and can use email facility.

INBOX: This is main dialog box to display inbox. Email can be taken from the server using Show
command. Email can be put on the server also using Write Mail command. Client also can click Log out to log out from the server. User can also delete the email messages from the server using Delete command.

WRITE MAIL: Here user compose email to be sent to the other users.

READ MAIL: Here mail is displayed when user clicks on show button of INBOX form.

6.4 Database Design: There are two tables, which are being used in this project. These have
made in Microsoft Access.

Login Table: There are three fields in this table:


ID Login Password

Message Table: This table contains following fields:


ID From To Subject Message

CHAPTER 7 Coding
7.1- Classes Used Server Side
1. CaboutDlg (Member Function) DoDataExchage(CdataExchange*,pDX); It exchanges the data from window to variables. CAboutDlg() : CDialog(CAboutDlg::IDD)

2. CMySocket (Member Function) AssertValid() const It use for CMySocket diagnostics. CMySocket(CDatabase* pdb) DoFieldExchange(CFieldExchange* pFX) Dump(CDumpContext& dc) const GetDefaultConnect() GetDefaultSQL()

3. CEmailServerApp (Member Function) CEmailServerApp() This function is used for CEmailServerApp construction. InitInstance() This function is used for CEmailServerApp initialization

4. CEmailServerDlg (Member Function) CEmailServerDlg(CWnd* pParent /*=NULL*/) DoDataExchange(CDataExchange* pDX) It exchanges the data from window to variable. Login_Check(char *r) It checks the validation of the client by matching the name and password from the database. OnAccept() This function is used to accept the data from the client and takes action according to the first character of the message. OnClose() This function is called when client close the connection from server. OnInitDialog() It initializes variables etc before opening window. OnOK() This function is called to start the server. OnSysCommand(UINT nID, LPARAM lParam) OnQueryDragIcon(); The system calls this to obtain the cursor to display while the user drags The minimized window. Delete_Message(char *r) This function is used to delete the email from the server. Inbox(char *r) This function is used to display the inbox of a particular client. Read_Message(char *r) This function is used to send the message to the client when a client wants to see the message. Store_Message(char *r)

This function is used to store the message in the database when a user writes a mail to another user.. 5. CMSocket: Derivative class of CSocket to provide Socket functionality. (Member Function) CMSocket() This is used for Socket construction. ~CMSocket() This function is used for destroy the Socket. OnAccept(int nErrorCode) OnClose(int nErrorCode) SetParent(CDialog *pWnd)

Client side
1. CAboutDlg (Member Function) DoDataExchange(CDataExchange* pDX) It exchanges the data from window to variables. 2. CInbox: Derivative class of CDialog provides the Inbox window. (Member Function) CInbox(CWnd* pParent /*=NULL*/) DoDataExchange(CDataExchange* pDX) It exchanges the data from window to variables. OnDelete() This function is called when user clicks on Delete button. OnShow() This function is called when user clicks on Show button. OnWriteMail() This function is called when user clicks on Write Mail button. OnLogOut() This function is called when user clicks on Log Out button. 3. CReadMail: Derivative class of CDialog to read the incoming mail. (Member Function) CReadMail(CWnd* pParent /*=NULL*/) DoDataExchange(CDataExchange* pDX) It exchanges the data from window to variables. 4. CEmailClientApp: (Member Function) CEmailClientApp()

This function is used to CEmailClientApp construction. InitInstance() This function is used to CEmailClientApp initialization. 5. CEmailClientDlg: Derivative class of CDialog provides the user authentication dialog and starts the client software. (Member Function) CEmailClientDlg(CWnd* pParent /*=NULL*/) DoDataExchange(CDataExchange* pDX) It exchanges the data from window to variables. OnInitDialog() It initializes variables etc before opening window. OnOK() This function is connecting to user authentication dialog. OnSysCommand(UINT nID, LPARAM lParam)

6. CLogin: Derivative class of CDialog provides the user authentication. (Member Function) CLogin(CWnd* pParent /*=NULL*/) DoDataExchange(CDataExchange* pDX) It exchanges the data from window to variables. OnOK() This function is used to check login and password. If the user is valid then provide the next window otherwise give suitable messages. 7. CWritemail: Derivative class of CDialog used for composing an email. (Member Function) CReadMail(CWnd* pParent /*=NULL*/) DoDataExchange(CDataExchange* pDX) It exchanges the data from window to variables. OnClose()

This function is used to close the Write Mail dialog box. OnSend() This function is used to send the composed mail to the server. Server stores the mail for displaying to that particular client for which it is intended.

7.2- Resource View: Server Side


1. Dialog: IDD_ABOUTBOX // About Window. IDD_EMAILSERVER_DIALOG // Window asking to execute the server program. 2. Icon: IDR_MAINFRAME 3. String Table 4.Version

Client side
1. Dialog: IDD_ABOUTBOX // About Window. IDD_COMPOSE // For composing messages IDD_INBOX // For opening Inbox of a particular client IDD_Readmail // For Showing incoming mail IDD_EMAILCLIENT_DIALOG // For providing the user authentication dialog or exit. IDD_LOGIN // For the user authentication 2. Icon:

IDR_MAINFRAME 3. String Table: 4. Version:

7.3- File View: Server File


1. Source File: emailserver.cpp emailserver.rc emailserverDlg.cpp MSocket.cpp MySocket.cpp StdAfx.cpp

2. Header File: emailserver.h emailserverDlg.h MSocket.h MySocket.h Resource.h StdAfx.h

3. Resource File: emailserver.ico emailserver.rc2 ReadMe.txt

4. External Dependencies basetsd.h

Client Files
1. Source File: Inbox.cpp Readmail.cpp emailClient.cpp emailClient.rc emailClientDlg.cpp Login.cpp Writemail.cpp StdAfx.cpp

2. Header File: Inbox.h Readmail.h emailClient.h emailClientDlg.h Login.h Writemail.h Resource.h StdAfx.h

3. Resource File: emailClient.ico emailClient.rc2 ReadMe.txt

4. External Dependencies basetsd.h

7.4- Socket programming:

MFC supplies two classes to support programming network application with the Windows Socket API. Class CAsyncSocket encapsulates the windows Socket API one-for-one, giving advanced networks programmers the most power and flexibility. Class Csocket provides a simplified interface for serializing data to and from a CArchive object. Easiest solutions has got the extensive experience of Socket Programming above four years, We have extensively worked on socket programming in different languages like VB, VC++ and Java. Brief Description of Products in which Socket Programming is used: A socket is a communications connection point (endpoint) that you can name and address in a network the connection that a socket provides can be connection-oriented or connectionless.

Connection-oriented communication implies that a connection is established, dialog The (the and a the that service program) the between program the server

programs will follow. provides establishes

connection. It assigns itself a name that identifies where to obtain that service. The client of the service (the client program) must request the service of the server program. The client does this by connecting to the distinct name that the server program has designated. It is similar to dialing a telephone number (an identifier) and making a connection with another party that is offering a service (for example, a plumber). When the receiver of the call (the server) answers the telephone, the connection is established. The plumber verifies that you have reached the correct party, and the connection remains active as long as both parties require it. Connection remains active as long as both parties require it.

Connectionless communication implies that no connection is established over which a dialog or data transfer can take place. Instead, the server program designates a name that identifies where to reach it (much like a post office box). By sending a letter to a post office box, you cannot be absolutely sure the letter is received. You may have to send another letter to reestablish communication.

Socket Communication was preferred over other IPC methods because of the advantages: 1. The processes that use a socket can reside on the same system or on different systems on

different networks 2. Typical system configuration places the server on one machine, with the clients on other machines.

The clients connect to the server, exchange information, and then disconnect.

7.4.1- Definition of a socket: A socket is a communication endpoint - an object through which a Windows Sockets application sends or receives packets of data across a network. A Socket has a type and is associated with a running process, and it may have a name. Currently, Sockets generally exchange data only with other Sockets in the same "communication domain", which uses the Internet Protocol Suite. Two Socket type are available: Stream sockets

Provide for a data flow without record boundaries - a stream of bytes. Streams are guaranteed to be delivered and to be correctly sequenced and unduplicated. Datagram socket

Datagram socket support a record-oriented data flow that is not guaranteed to be delivered and may not be sequenced as sent or unduplicated. Sockets are highly useful in at least three communication contexts: Client/Server models. Peer-to-peer scenarios, such as chat applications. Making remote procedures calls (RPC) by having the receiving application message as a function call. interpret a

(i) CSocket Class: CAsyncsocket objects represent a window socket an end point of network communication. Class CAsyncsocket encapsulates the windows Socket API, providing an objectoriented abstraction for programmers who want to use windows Socket in conjunction with MFC. This class is based on the assumption that you understand network communication. You are responsible for handling blocking, byte order difference, and conversions between Unicode and multibyte character set (MBCS) strings. Class CSocket derives from CAsyncSocket and inherits its encapsulation of the windows Socket API than that of a CAsynSocket object. CSocket works with class CSocket file and CArchive to message the sending and receiving of data. CArchive does not have a base class. (ii) CArchive Class: The CArchive class allows we to save a complex network of objects in a permanent binary form (usually disk storage) that persist after those objects are deleted. Later you

can load the objects from persisting storage, reconstituting them in memory. This process of making data persistent is called serialization. We can think an archive object as a kind of binary stream. Like an input/output stream, an archive is associated with a file and permits the buffered writing and reading of data to and from storage. An input/output stream processes sequence of ASCII characters, but an archive processes binary object data in the efficient, nonredundant format. We must create a CFile object before we can create a CArchive object. In addition, we must ensure that the archives load/store status is compatible with the files open mode. We are limited to one active archive per file. When we construct a CArchive object, we attach it to an object of class CFile (or a derived class) that represent an open file. We also specify whether the archive will be used for loading or storing. The overloaded extraction (>>) and insertion (<<) operators are convenient archive programming interfaces that support both primitive types and CObject-derived classes. CArchive also supports programming with the MFC Windows sockets classes CSocket and CSocketFile. (iii) CFile class: CFile is the base class for Microsoft foundation file classes. It directly provides unbuffered, binary disk input/output services, and it indirectly supports text file and memory files through its derived classes. CFile works in conjunction with the CArchive classes to support serialization of Microsoft Foundation objects. (iv) CSocketFile Class: A CSocketFile object is a CFile object use for sending and receiving data across a network via Windows Socket. You can attach the CSocketFile object to a CSocket object for this purpose. We also can and usually do attach the CSocketFile object to a CArchive object to simply sending and receiving data using MFC serialization. To serialization (send) data, you insert it into archive, with class CSocketFile member function to the CSocket object. To deserialize (receive) data, you extract from the archive. These cause the archive to call CSocketFile member function to read data from the CSocket object.

7.4.2- How Sockets with Archives Work:


This article explains how CSocket object, a CSocket file object, and a CArchive object are combined to simplify sending and receiving data via a Windows Socket. A CArchive object manages a buffer. When the buffer of a storing (Sending) Archive is full, an associated CFile object writes out the buffers contents. Flushing the buffer of an archive attached to a Socket is equivalent to sending a

message. When the buffer of loading (Recieving) archive is full, the CFile object stops reading until the buffer is available again. The CSocket file object calls member function of its CSocket object to send or receive data.

The following figure shows the relationship among these objects on both side of the communication.
CArchive, CSocketFile, and CSocket

The purpose of this apparent complexity is to shield from the necessity of managing the details of the Socket. We simplify create the Socket, the file, and the archive, and then begin sending or receiving data by inserting it to the archive or extracting it from the archive CArchive, CSocket File, and CSocket manage the details behind the scenes [4].

7.4.3- The CSocket Programming Model:


To setup communication between a server and a client Socket 1. Construct a CSocket object. 2. Use the object to create the underline SOCKET handle. For a CSocket client object, we should normally use the default parameter to create, unless we need a datagram socket. For a CSocket server object, we must specify a port in the create call. Note CArchive doesnt work with datagram sockets. If we want to use CSocket for a datagram socket, we must use the class as we would CAsyncSocket without an archive. Because datagrams are unreliable (not guaranteed to arrive and may be repeated or out of sequence), they

arent compatible with serialization via an archive. we expect a serialization operation to complete to reliably and in sequence. If we try to use CSocket with a CArchive object for a datagram, an MFC assertion fails. 3. If the Socket is a client, call CasyncSocketc :: connect to connect the socket object to a server socket. -orIf the socket is a server, call CasyncSocket :: Listen to begin listening for connect attempts from a client. Upon receiving a connection request, accept it by calling CAsynSocket :: Accept. 4. Create a CSocket File object, associating the CSocket object with it. 5. Create a CArchive object for either loading (receiving) or storing (sending) data. The archive is associated with the CSocket File object. Keep in mind that CArchive doesnt work with datagram Sockets. 6. Use the CArchive object to pass data between the client and server Sockets. Keep in mind that a given CArchive object moves data in one direction only: Either for loading (receiving) or storing (sending). In same case well use two CArchive objects one for sending data, the other for receiving acknowledgements. After accepting a connection and setting up the archive, we can perform such tasks as validating passwords. 7. destroy the archive, Socket File and Socket objects

7.4.4- Sequence of Operations for a Stream Socket Communication:


Up to the point of constructing a CSocketFile object, the following sequence is accurate (with a few parameter differences) for both CAsyncSocket and CSocket. From that point on, the sequence is strictly for CSocket. The following table illustrates the sequence of operations for setting up communication between a client and a server. Setting Up Communication Between a Server and a Client

Server
// construct a socket CSocket sockSrvr; // create the SOCKET

Client
// construct a socket CSocket sockClient; // create the SOCKET

sockSrvr.Create(nPort);1,2 // start listening sockSrvr.Listen( );

sockClient.Create( );2

// seek a connection sockClient.Connect(strAddr, nPort);3,4 // construct a new, empty socket CSocket sockRecv; // accept connection sockSrvr.Accept( sockRecv ); // construct file object CSocketFile file(&sockRecv); // construct an archive CArchive arIn(&file, CArchive::load);
5

// construct file object CSocketFile file(&sockClient); // construct an archive CArchive arIn(&file, CArchive::load);

-orCArchive arOut(&file, CArchive::store);

-orCArchive arOut(&file, CArchive::store);

or Both
// use the archive to pass data: arIn >> dwValue;

or Both
// use the archive to pass data: arIn >> dwValue;

-orarOut << dwValue;6

-orarOut << dwValue;6

1. Where nPort is a port number.

2. The server must always specify a port so clients can connect. The Create call sometimes also specifies an address. On the client side, use the default parameters, which ask MFC to use any available port. 3. Where nPort is a port number and strAddr is a machine address or an Internet Protocol (IP) address. 4. Machine addresses can take several forms: ftp.microsoft.com, ucsd.edu. IP addresses use the dotted number form 127.54.67.32. The Connect function checks to see if the address is a dotted number (although it doesnt check to ensure the number is a valid machine on the network). If not, Connect assumes a machine name of one of the other forms. 5. When Accept is called on the server side, a reference is passed to a new socket object. If this socket
object goes out of scope, the connection closes. MFC connects the new object to a SOCKET handle. 6. The archive and the socket file are closed when they go out of scope. The socket objects destructor also calls the Close member function for the socket object when the object goes out of scope or is deleted.

7.5- Optimization of Code:


This software allows the user to specify the servers address. This makes the client software faster and also one can move the server to another place. We are not using broadcast or multicast protocol to find server to avoid unnecessary complexity. We are putting our concentration to make the email server simple and efficient as possible. This software is not also string servers-IP in a file because file may not available and then software may fail to search for it server. We are leaving our software flexible to adopt an extended version of the software that uses other ways to find server-IP. So if user finds it easier or it needs to stores servers address in a file he/she may renovate the software easily. In nut-cell we can say By allowing user to specify the servers-IP, FTP makes itself faster, less complex and flexible to move server. The basic design model uses the analysis model as the framework for implementation. The analysis model captures the logic information about the system, while the design model adds details to support efficient information access. During design optimization we must: Add redundant association to minimize access cost and maximize convenience. Rearrange the computation for greater efficiency. Save derived attributes to avoid re-computation of complicated expression.

During report generation we used optimization techniques of rearranging execution order for greater efficiency. Redundancy of data in the table has been removed through Normalization technique. All the tables are designed in normalized form. Implicit and explicit locks are used wherever needed. Resource Optimization We optimize the resource also. During coding we have kept the strict vigilance to use the same function again and again by writing the code in a module. Readability OptimizationThe following points are kept in the mind while writing the software:1. The variable names are based on the field name. 2. The comments on each line of code are provided to make the source code more meaningful. 3. Codes are fully made readable to anyone. Performance Optimization1. Queries on the database are optimized by performing the selection and projection i.e. the data is projected and then selected to minimize the data transfer for server to the client. 2. The connection is closed as soon as that is reached to the client to minimize the network traffic. Behavioral Optimization1. The screen is optimized on the basis of input form; the flow of input is set using the tab order. 2. System makes minimum use of message box, by which the speed is maintained.

7.6- Validation Checks:


Validation checks are used at a broad level in this software to avoid any kind of confusion or accidental access of any kind of data. In case of accident or illegal accessing a problem may occur. Validation checks are enforced at the client side as well as the server side. Correction of mistakes is done by displaying warning messages or invalid declaration.

CHAPTER 8 Implementation and Maintenance


8.1- Testing: Testing is a process, which reveals in the program. It is an important quality measure
employed during software development. The testing method varies from project to project depending on the nature and complexity of the system, working environment, etc. During testing, the program is executed with a set of test cases and the output of the program for the test cases is evaluated to determine if the is performing as it is expected to do. In this S/W White-Box Testing is conducted to closely examine the procedural detail. To test the logical path, Test cases are provided that exercise specific sets of conditions and or loops. It is not possible to test each logical path so a limited no. of important logical paths are selected and tested. The attributes of both black & white box testing are combined to provide an approach that validates the S/W interface and selectively ensures that the interval workings of the S/W are correct. Black and white box testing are complementary to each other. Black-box tests are used to demonstrate the S/W functions are operational, that input is properly accepted and output is correctly produced, and that the integrity of database is maintained. In this S/W it is tested that when we transfer email, it is transferred properly.

8.2- System Security Measures:


Because server often needs to access data, computations, or protocol ports that the operating system protects, server s/w usually requires special system privileges. Because a server executes with special system privilege, care must be taken to ensure that it does not inadvertently pass privilege on to the clients that use it. For example, a file server that operates as a privileged programmed must contain code to check whether a given client can access a given file. The server cannot rely on the usual operating system checks because its privileged status overrides them. So email server contains code that handles the issues of: Authentication- verifying the identity of the client Authorization- determining whether a given client is permitted to access the service of the server supplies Data security- guaranteeing that data is not unintentionally revealed or compromised

Privacy-

keeping information about in individual from an unauthorized access.

Protection- guaranteeing that network applications can not abuse system recourses.

CHAPTER 9
Future scope and further enhancement of the project:
This software can be updated in future to provide following feature: 1. Voice communication can be added. 2. Chatting facility with in an organization can be added. 3. Video conferencing software can be made in which communication of audio and video will be possible. 4. More Security features can be added for authentication, mail delivery etc. Cryptography may be used for this purpose.

References

1. Douglas E. Comer/ David L.Stevens, internetworking with TCP/IP, Vol 3. 2. Pankaj Jalote, An Integrated Approach to Software Engineering. 3. Tananbaum, Computer Networks. 4. MSDN Library. 5. ABEYSUNDARA, B.W., and KAMAL, A.E.: High Speed Local Area Networks and Their Performance Computing Surveys, Vol. 23, june1991. 6. CAMPBELL, A.,COULSON,G., and HUTCHISON,D.:A Quality of service Architecture, Computer Communication. Rev., vol 24 April 1994 7.COMER,7. 7. D.E.: Internetworking With TCP/IP, vol. 1, 3rd ed., Englewood Cliffs, Nj: Prentice Hall, 1995. 8. DELODDERE, D., VERBIEST, W., and VERHILLE: Interative Video On demand, IEEE Commun.Magazine, vol. 32, pp.82-88, May 1994. 9. Douglas E.Comer/ David L. Stevens, Internetworking with TCP/IP, Vol. III. 10. NAGLE, j.: Congestion Control in TCP/IP, Computer Commun., Rev., Vol. 14. 11. PAXSON, V.: Groh Trends in Wide Area TCP Connection., IEEE Network Magazine, vol. 8, pp. 8-17, July /Aug. 1994. 12. WALRAAND, J.: Communication Networks: first course, Homewood, II.:Lrwinm,1991. 13. ABRAMSON, N. and F.KUO(EDS)[1973], Computer Communication Networks, Prentice Hall, Englewood cliffs, New Jersey. 14. BOGGS, D., J.SHOCH,E. TAFT, and R. 15. METCALFE[April 1980], Pup: An Internet Work Architecture, IEEE

Glossary
INTERNET
A worldwide hierarchy of computer networks using a variety of protocols. At its highest level the Internet is connected by backbone networks such as ARPAnet, NSFNet, and MILNET. The backbones connect transit networks, which in turn connect stub networks. Logically, Internet participants are represented by a domain such as .com, .org, and .edu, by a logical network within the domain, and by a server within the logical network. SERVER A computer that provides shared resources to network users. USER INTERFACE The user interface uses standard Windows interface functionality along with a few additional features to make your development environment easy to use. The basic features that you use most often are windows and document views, toolbars, menus, directories, and keyboard shortcuts. MICROSOFT FOUNDATION CLASS The C++ class library that Microsoft provides with its C++ compiler to assist programmers in creating Windows-based applications. MFC hides the fundamental Windows API in class hierarchies so that programmers can write a Windows-based application without needing to know the details of the native Windows API. URL (Uniform Resource Locator) Identifies the full path of a document, graphic, or other file on the Internet or on an intranet. A URL expresses the protocol (such as FTP or HTTP) to be accessed and the file's location. A URL may also specify an Internet e-mail address or a newsgroup. Some examples of URLs are: http://www.someones.homepage/default.html ftp://ftp.server.somewhere/ftp.file

SOURCE CODE

SERVER SIDE CODE


emailserver.cpp : Defines the class behaviors for the application.
#include "stdafx.h" #include "emailserver.h" #include "emailserverDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CEmailserverApp BEGIN_MESSAGE_MAP(CEmailserverApp, CWinApp) //{{AFX_MSG_MAP(CEmailserverApp) // NOTE - the ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //}}AFX_MSG ON_COMMAND(ID_HELP, CWinApp::OnHelp) END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CEmailserverApp construction CEmailserverApp::CEmailserverApp() { // TODO: add construction code here, // Place all significant initialization in InitInstance } ///////////////////////////////////////////////////////////////////////////// // The one and only CEmailserverApp object CEmailserverApp theApp; ///////////////////////////////////////////////////////////////////////////// // CEmailserverApp initialization

BOOL CEmailserverApp::InitInstance() { if (!AfxSocketInit()) { AfxMessageBox(IDP_SOCKETS_INIT_FAILED); return FALSE; } AfxEnableControlContainer(); // Standard initialization // If you are not using these features and wish to reduce the size // of your final executable, you should remove from the following // the specific initialization routines you do not need. #ifdef _AFXDLL Enable3dControls(); #else Enable3dControlsStatic(); // Call this when linking to MFC statically #endif SetDialogBkColor(RGB(240,150,150)); CEmailserverDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) { // TODO: Place code here to handle when the dialog is // dismissed with OK } else if (nResponse == IDCANCEL) { // TODO: Place code here to handle when the dialog is // dismissed with Cancel } // Since the dialog has been closed, return FALSE so that we exit the // application, rather than start the application's message pump. return FALSE; } // Call this when using MFC in a shared DLL

emailserver.h : main header file for the EMAILSERVER application

#if !defined(AFX_EMAILSERVER_H__03D17FCB_8F56_4C99_B75B_8B87DF61F5D4__INCLUDED_) #define AFX_EMAILSERVER_H__03D17FCB_8F56_4C99_B75B_8B87DF61F5D4__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols

///////////////////////////////////////////////////////////////////////////// // CEmailserverApp: // See emailserver.cpp for the implementation of this class // class CEmailserverApp : public CWinApp { public: CEmailserverApp(); // Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CEmailserverApp) public: virtual BOOL InitInstance(); //}}AFX_VIRTUAL // Implementation //{{AFX_MSG(CEmailserverApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //}}AFX_MSG DECLARE_MESSAGE_MAP()

};

///////////////////////////////////////////////////////////////////////////// //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_EMAILSERVER_H__03D17FCB_8F56_4C99_B75B_8B87DF61F5D4__INCLUDED_)

emailserverDlg.cpp : implementation file


#include "stdafx.h" #include "emailserver.h" #include "emailserverDlg.h" #include "afxdb.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CAboutDlg dialog used for App About class CAboutDlg : public CDialog { public: CAboutDlg(); // Dialog Data //{{AFX_DATA(CAboutDlg) enum { IDD = IDD_ABOUTBOX }; //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CAboutDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); //}}AFX_VIRTUAL // Implementation protected: //{{AFX_MSG(CAboutDlg) //}}AFX_MSG DECLARE_MESSAGE_MAP() }; CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD) // DDX/DDV support

{ //{{AFX_DATA_INIT(CAboutDlg) //}}AFX_DATA_INIT } void CAboutDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CAboutDlg) //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CAboutDlg, CDialog) //{{AFX_MSG_MAP(CAboutDlg) // No message handlers //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CEmailserverDlg dialog CEmailserverDlg::CEmailserverDlg(CWnd* pParent /*=NULL*/) : CDialog(CEmailserverDlg::IDD, pParent) { //{{AFX_DATA_INIT(CEmailserverDlg) // NOTE: the ClassWizard will add member initialization here //}}AFX_DATA_INIT // Note that LoadIcon does not require a subsequent DestroyIcon in Win32 m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME); } void CEmailserverDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CEmailserverDlg) // NOTE: the ClassWizard will add DDX and DDV calls here //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CEmailserverDlg, CDialog) //{{AFX_MSG_MAP(CEmailserverDlg)

ON_WM_SYSCOMMAND() ON_WM_PAINT() ON_WM_QUERYDRAGICON() //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CEmailserverDlg message handlers BOOL CEmailserverDlg::OnInitDialog() { CDialog::OnInitDialog(); // Add "About..." menu item to system menu. // IDM_ABOUTBOX must be in the system command range. ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX); ASSERT(IDM_ABOUTBOX < 0xF000); CMenu* pSysMenu = GetSystemMenu(FALSE); if (pSysMenu != NULL) { CString strAboutMenu; strAboutMenu.LoadString(IDS_ABOUTBOX); if (!strAboutMenu.IsEmpty()) { pSysMenu->AppendMenu(MF_SEPARATOR); pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu); } } // Set the icon for this dialog. The framework does this automatically // when the application's main window is not a dialog SetIcon(m_hIcon, TRUE); SetIcon(m_hIcon, FALSE); // Set big icon // Set small icon

// TODO: Add extra initialization here listen.SetParent(this); data.SetParent(this); Number_Meeting(); return TRUE; // return TRUE unless you set the focus to a control

} void CEmailserverDlg::OnSysCommand(UINT nID, LPARAM lParam) { if ((nID & 0xFFF0) == IDM_ABOUTBOX) { CAboutDlg dlgAbout; dlgAbout.DoModal(); } else { CDialog::OnSysCommand(nID, lParam); } } // If you add a minimize button to your dialog, you will need the code below // to draw the icon. For MFC applications using the document/view model, // this is automatically done for you by the framework. void CEmailserverDlg::OnPaint() { if (IsIconic()) { CPaintDC dc(this); // device context for painting SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0); // Center icon in client rectangle int cxIcon = GetSystemMetrics(SM_CXICON); int cyIcon = GetSystemMetrics(SM_CYICON); CRect rect; GetClientRect(&rect); int x = (rect.Width() - cxIcon + 1) / 2; int y = (rect.Height() - cyIcon + 1) / 2; // Draw the icon dc.DrawIcon(x, y, m_hIcon); } else { CDialog::OnPaint();

} } // The system calls this to obtain the cursor to display while the user drags // the minimized window. HCURSOR CEmailserverDlg::OnQueryDragIcon() { return (HCURSOR) m_hIcon; } void CEmailserverDlg::OnOK() { // TODO: Add extra validation here listen.Create(4000); listen.Listen();

// }

CDialog::OnOK();

void CEmailserverDlg::Login_Check(char *r) { CString login=r; CString lp=login.Mid(2); int f=lp.Find(':'); CString l=lp.Left(f); CString p=lp.Mid(f+1); CDatabase db; db.OpenEx(_T("DSN=email"),CDatabase::noOdbcDialog); CRecordset rs(&db); rs.Open( CRecordset::dynaset, _T( "Select * from Login" ) ); CString ld,pd; CString ok="OK"; CString notok="NOTOK"; int flag=0; while(!rs.IsEOF()) { rs.GetFieldValue(1,ld); rs.GetFieldValue(2,pd); if(ld==l && pd==p)

{ data.Send(ok,ok.GetLength()); flag=1; break; } rs.MoveNext(); } if(flag==0) data.Send(notok,notok.GetLength()); rs.Close(); db.Close(); data.Close(); //AfxMessageBox(l+"hi"+p); } void CEmailserverDlg::Inbox(char *r) { CString l=r+1; CDatabase db; db.OpenEx(_T("DSN=email"),CDatabase::noOdbcDialog); CRecordset rs(&db); rs.Open( CRecordset::dynaset, _T( "Select * from Message" ) ); CString msg,pd,to,from,subject,no,d; CDBVariant varValue;

while(!rs.IsEOF()) { rs.GetFieldValue(2,to); rs.GetFieldValue(5,d); if(to==l) { if(d=='N') { rs.GetFieldValue("ID",no); // int n=varValue;

//

_ltoa(n,no,10); rs.GetFieldValue(1,from); rs.GetFieldValue(3,subject);

msg=msg+no+"^"+from+"^"+subject+"^"; } } rs.MoveNext(); } data.Send(msg,msg.GetLength()); rs.Close(); db.Close(); data.Close(); } void CEmailserverDlg::Store_Message(char *r) { CString msg=r+1; add.Open(); ////add.MoveLast(); //CString num; //add.GetFieldValue(Mno,number); //num=add.m_Mno; //int number; //number=atoi(num); //number++; //add.MoveFirst(); number++; add.AddNew(); CString caller; add.m_ID=number; //add.m_Caller="pankaj"; int s=msg.Find('^'); caller=msg.Left(s); add.m_From=caller; CString remain=msg.Mid(s+1); s=remain.Find('^'); add.m_To=remain.Left(s); remain=remain.Mid(s+1); s=remain.Find('^');

add.m_Subject=remain.Left(s); add.m_Message=remain.Mid(s+1); add.m_Deleted="N"; add.Update(); //CString cmd="INSERT INTO Meeting (Mno,Caller,Topic,Called,Date,Time) VALUES _(12,'Harry')"; //db.ExecuteSQL(cmd); //db.Close(); add.Close();

data.Close(); } void CEmailserverDlg::Number_Meeting() { CDatabase db; db.OpenEx(_T("DSN=email"),CDatabase::noOdbcDialog); CRecordset rs(&db); rs.Open( CRecordset::dynaset, _T( "Select ID from Message" ) ); CString num; if(rs.GetRecordCount()==0) number=-1; else { rs.MoveLast(); rs.GetFieldValue("ID",num); } number=atoi(num); rs.Close(); db.Close(); } void CEmailserverDlg::Read_Message(char *r) { CString no=r+1; CDatabase db; db.OpenEx(_T("DSN=email"),CDatabase::noOdbcDialog); CRecordset rs(&db); rs.Open( CRecordset::dynaset,

_T( "Select * from Message" ) ); CString msg,pd,to,from,subject,d; while(!rs.IsEOF()) { rs.GetFieldValue("ID",pd); if(pd==no) { rs.GetFieldValue(1,from); rs.GetFieldValue(2,to); rs.GetFieldValue(3,subject); rs.GetFieldValue(4,d); break; } rs.MoveNext(); } rs.Close(); db.Close(); msg=from+"^"+to+"^"+subject+"^"+d; data.Send(msg,msg.GetLength()); data.Close(); } void CEmailserverDlg::OnAccept() { listen.Accept(data); char *r=new char[1024]; int rlen=data.Receive(r,1023); r[rlen]=NULL; //AfxMessageBox(r); if(r[0]=='M') { // AfxMessageBox("yaar"); Login_Check(r); } if(r[0]=='I') { Inbox(r); } if(r[0]=='S') {

Store_Message(r); } if(r[0]=='R') { Read_Message(r); } if(r[0]=='D') { Delete_Message(r); } delete r; } void CEmailserverDlg::OnClose() { data.Close(); } void CEmailserverDlg::Delete_Message(char *r) { CString nl=r+1; int s=nl.Find("^"); CString num=nl.Left(s); CString l=nl.Mid(s+1); add.Open(); CString a; while(!add.IsEOF()) { add.GetFieldValue("ID",a); //AfxMessageBox(a); //AfxMessageBox("num:"+num+"end"); if(a==num) { add.Edit(); add.m_Deleted="Y"; add.Update(); break; } add.MoveNext(); } add.Close();

CDatabase db; db.OpenEx(_T("DSN=email"),CDatabase::noOdbcDialog); CRecordset rs(&db); rs.Open( CRecordset::dynaset, _T( "Select * from Message" ) ); CString msg,pd,to,from,subject,no,d; CDBVariant varValue; while(!rs.IsEOF()) { rs.GetFieldValue(2,to); rs.GetFieldValue(5,d); if(to==l) { if(d=='N') { rs.GetFieldValue("ID",no); // // int n=varValue; _ltoa(n,no,10); rs.GetFieldValue(1,from); rs.GetFieldValue(3,subject); msg=msg+no+"^"+from+"^"+subject+"^"; } } rs.MoveNext(); } data.Send(msg,msg.GetLength()); rs.Close(); db.Close(); data.Close(); }

emailserverDlg.h : header file


#if !defined(AFX_EMAILSERVERDLG_H__2B29C742_6CA9_41BE_A5A9_59AABAE27B4A__INCLUDED_) #define AFX_EMAILSERVERDLG_H__2B29C742_6CA9_41BE_A5A9_59AABAE27B4A__INCLUDED_ #include "MSocket.h" #include "MySocket.h" #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 ///////////////////////////////////////////////////////////////////////////// // CEmailserverDlg dialog class CEmailserverDlg : public CDialog { // Construction public: void Delete_Message(char* r); void OnClose(); void OnAccept(); void Read_Message(char *r); void Number_Meeting(); int number; CMySocket add; void Store_Message(char *r); void Inbox(char *); void Login_Check(char *); // char r[1024]; CEmailserverDlg(CWnd* pParent = NULL); // standard constructor // Dialog Data //{{AFX_DATA(CEmailserverDlg) enum { IDD = IDD_EMAILSERVER_DIALOG }; // NOTE: the ClassWizard will add data members here //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CEmailserverDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support // Added by ClassView

//}}AFX_VIRTUAL // Implementation protected: HICON m_hIcon; // Generated message map functions //{{AFX_MSG(CEmailserverDlg) virtual BOOL OnInitDialog(); afx_msg void OnSysCommand(UINT nID, LPARAM lParam); afx_msg void OnPaint(); afx_msg HCURSOR OnQueryDragIcon(); virtual void OnOK(); //}}AFX_MSG DECLARE_MESSAGE_MAP() private: CMSocket data; CMSocket listen; }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif NCLUDED_) // defined(AFX_EMAILSERVERDLG_H__2B29C742_6CA9_41BE_A5A9_59AABAE27B4A__I !

MSocket.cpp : implementation file


#include "stdafx.h" #include "emailserver.h" #include "MSocket.h" #include "emailserverDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CMSocket CMSocket::CMSocket() { } CMSocket::~CMSocket() { }

// Do not edit the following lines, which are needed by ClassWizard. #if 0 BEGIN_MESSAGE_MAP(CMSocket, CSocket) //{{AFX_MSG_MAP(CMSocket) //}}AFX_MSG_MAP END_MESSAGE_MAP() #endif // 0

///////////////////////////////////////////////////////////////////////////// // CMSocket member functions void CMSocket::SetParent(CDialog *pWnd) { m_pWnd=pWnd; }

void CMSocket::OnAccept(int nErrorCode) { // TODO: Add your specialized code here and/or call the base class if(nErrorCode==0) ((CEmailserverDlg*)m_pWnd)->OnAccept(); }

void CMSocket::OnClose(int nErrorCode) { // TODO: Add your specialized code here and/or call the base class if(nErrorCode==0) ((CEmailserverDlg*)m_pWnd)->OnClose(); }

MSocket.h : header file


#if !defined(AFX_MSOCKET_H__F882A985_9EF3_4EB2_B9D1_A239333C3FDB__INCLUDED_) #define AFX_MSOCKET_H__F882A985_9EF3_4EB2_B9D1_A239333C3FDB__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 // MSocket.h : header file // ///////////////////////////////////////////////////////////////////////////// // CMSocket command target class CMSocket : public CSocket { // Attributes public: // Operations public: CMSocket(); virtual ~CMSocket(); // Overrides public: void SetParent(CDialog *pWnd); // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CMSocket) //}}AFX_VIRTUAL // Generated message map functions //{{AFX_MSG(CMSocket) // NOTE - the ClassWizard will add and remove member functions here. //}}AFX_MSG // Implementation protected: virtual void OnClose(int nErrorCode); virtual void OnAccept(int nErrorCode); private:

CDialog* m_pWnd; }; ///////////////////////////////////////////////////////////////////////////// //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_MSOCKET_H__F882A985_9EF3_4EB2_B9D1_A239333C3FDB__INCLUDED_)

MySocket.cpp : implementation file


#include "stdafx.h" #include "emailserver.h" #include "MySocket.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CMySocket IMPLEMENT_DYNAMIC(CMySocket, CRecordset) CMySocket::CMySocket(CDatabase* pdb) : CRecordset(pdb) { //{{AFX_FIELD_INIT(CMySocket) m_ID = 0; m_From = _T(""); m_To = _T(""); m_Subject = _T(""); m_Message = _T(""); m_Deleted = _T(""); m_nFields = 6; //}}AFX_FIELD_INIT m_nDefaultType = snapshot; }

CString CMySocket::GetDefaultConnect() { return _T("ODBC;DSN=email"); } CString CMySocket::GetDefaultSQL() {

return _T("[Message]"); } void CMySocket::DoFieldExchange(CFieldExchange* pFX) { //{{AFX_FIELD_MAP(CMySocket) pFX->SetFieldType(CFieldExchange::outputColumn); RFX_Long(pFX, _T("[ID]"), m_ID); RFX_Text(pFX, _T("[From]"), m_From); RFX_Text(pFX, _T("[To]"), m_To); RFX_Text(pFX, _T("[Subject]"), m_Subject); RFX_Text(pFX, _T("[Message]"), m_Message); RFX_Text(pFX, _T("[Deleted]"), m_Deleted); //}}AFX_FIELD_MAP } ///////////////////////////////////////////////////////////////////////////// // CMySocket diagnostics #ifdef _DEBUG void CMySocket::AssertValid() const { CRecordset::AssertValid(); } void CMySocket::Dump(CDumpContext& dc) const { CRecordset::Dump(dc); } #endif //_DEBUG

MySocket.h : header file


#if !defined(AFX_MYSOCKET_H__303C1FDC_1B17_43F6_8258_4EB4060F95C8__INCLUDED_) #define AFX_MYSOCKET_H__303C1FDC_1B17_43F6_8258_4EB4060F95C8__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 // MySocket.h : header file // #include<afxdb.h> ///////////////////////////////////////////////////////////////////////////// // CMySocket recordset class CMySocket : public CRecordset { public: CMySocket(CDatabase* pDatabase = NULL); DECLARE_DYNAMIC(CMySocket) // Field/Param Data //{{AFX_FIELD(CMySocket, CRecordset) long m_ID; CString m_From; CString m_To; CString m_Subject; CString m_Message; CString m_Deleted; //}}AFX_FIELD

// Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CMySocket) public: virtual CString GetDefaultConnect(); virtual CString GetDefaultSQL(); //}}AFX_VIRTUAL // Default connection string // Default SQL for Recordset

virtual void DoFieldExchange(CFieldExchange* pFX); // RFX support

// Implementation #ifdef _DEBUG virtual void AssertValid() const; virtual void Dump(CDumpContext& dc) const; #endif }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_MYSOCKET_H__303C1FDC_1B17_43F6_8258_4EB4060F95C8__INCLUDED_)

stdafx.cpp : source file that includes just the standard includes


// // #include "stdafx.h" emailserver.pch will be the pre-compiled header stdafx.obj will contain the pre-compiled type information

stdafx.h : include file for standard system include files


#if !defined(AFX_STDAFX_H__C8F930F9_A7CE_4774_BC95_B8E0041761B6__INCLUDED_) #define AFX_STDAFX_H__C8F930F9_A7CE_4774_BC95_B8E0041761B6__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #define VC_EXTRALEAN #include <afxwin.h> #include <afxext.h> #include <afxdisp.h> #include <afxdtctl.h> #include <afxcmn.h> // Exclude rarely-used stuff from Windows headers

// MFC core and standard components // MFC extensions // MFC Automation classes // MFC support for Internet Explorer 4 Common Controls // MFC support for Windows Common Controls

#ifndef _AFX_NO_AFXCMN_SUPPORT #endif // _AFX_NO_AFXCMN_SUPPORT #include <afxsock.h> //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_STDAFX_H__C8F930F9_A7CE_4774_BC95_B8E0041761B6__INCLUDED_) // MFC socket extensions

CLIENT SIDE CODE:


emailclient.cpp : Defines the class behaviors for the application.
#include "stdafx.h" #include "emailclient.h" #include "emailclientDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CEmailclientApp BEGIN_MESSAGE_MAP(CEmailclientApp, CWinApp) //{{AFX_MSG_MAP(CEmailclientApp) // NOTE - the ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //}}AFX_MSG ON_COMMAND(ID_HELP, CWinApp::OnHelp) END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CEmailclientApp construction CEmailclientApp::CEmailclientApp() { // TODO: add construction code here, // Place all significant initialization in InitInstance } ///////////////////////////////////////////////////////////////////////////// // The one and only CEmailclientApp object CEmailclientApp theApp; ///////////////////////////////////////////////////////////////////////////// // CEmailclientApp initialization BOOL CEmailclientApp::InitInstance() {

if (!AfxSocketInit()) { AfxMessageBox(IDP_SOCKETS_INIT_FAILED); return FALSE; } AfxEnableControlContainer(); // Standard initialization // If you are not using these features and wish to reduce the size // of your final executable, you should remove from the following // the specific initialization routines you do not need. #ifdef _AFXDLL Enable3dControls(); #else Enable3dControlsStatic(); #endif SetDialogBkColor(RGB(240,160,160)); CEmailclientDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) { // TODO: Place code here to handle when the dialog is // dismissed with OK } else if (nResponse == IDCANCEL) { // TODO: Place code here to handle when the dialog is // dismissed with Cancel } // Since the dialog has been closed, return FALSE so that we exit the // application, rather than start the application's message pump. return FALSE; } // Call this when linking to MFC statically // Call this when using MFC in a shared DLL

emailclient.h : main header file for the EMAILCLIENT application

#if !defined(AFX_EMAILCLIENT_H__25EB6E23_24CA_48B6_BEDB_5644BFDE2CED__INCLUDED_) #define AFX_EMAILCLIENT_H__25EB6E23_24CA_48B6_BEDB_5644BFDE2CED__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols

///////////////////////////////////////////////////////////////////////////// // CEmailclientApp: // See emailclient.cpp for the implementation of this class // class CEmailclientApp : public CWinApp { public: CEmailclientApp(); // Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CEmailclientApp) public: virtual BOOL InitInstance(); //}}AFX_VIRTUAL // Implementation //{{AFX_MSG(CEmailclientApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //}}AFX_MSG DECLARE_MESSAGE_MAP()

};

///////////////////////////////////////////////////////////////////////////// //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_EMAILCLIENT_H__25EB6E23_24CA_48B6_BEDB_5644BFDE2CED__INCLUDED_)

emailclientDlg.cpp : implementation file


#include "stdafx.h" #include "emailclient.h" #include "emailclientDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CAboutDlg dialog used for App About class CAboutDlg : public CDialog { public: CAboutDlg(); // Dialog Data //{{AFX_DATA(CAboutDlg) enum { IDD = IDD_ABOUTBOX }; //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CAboutDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); //}}AFX_VIRTUAL // Implementation protected: //{{AFX_MSG(CAboutDlg) //}}AFX_MSG DECLARE_MESSAGE_MAP() }; CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD) { // DDX/DDV support

//{{AFX_DATA_INIT(CAboutDlg) //}}AFX_DATA_INIT } void CAboutDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CAboutDlg) //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CAboutDlg, CDialog) //{{AFX_MSG_MAP(CAboutDlg) // No message handlers //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CEmailclientDlg dialog CEmailclientDlg::CEmailclientDlg(CWnd* pParent /*=NULL*/) : CDialog(CEmailclientDlg::IDD, pParent) { //{{AFX_DATA_INIT(CEmailclientDlg) m_ipaddress = _T(""); //}}AFX_DATA_INIT // Note that LoadIcon does not require a subsequent DestroyIcon in Win32 m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME); } void CEmailclientDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CEmailclientDlg) DDX_Text(pDX, IDC_IPADDRESS, m_ipaddress); //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CEmailclientDlg, CDialog) //{{AFX_MSG_MAP(CEmailclientDlg) ON_WM_SYSCOMMAND()

ON_WM_PAINT() ON_WM_QUERYDRAGICON() //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CEmailclientDlg message handlers BOOL CEmailclientDlg::OnInitDialog() { CDialog::OnInitDialog(); // Add "About..." menu item to system menu. // IDM_ABOUTBOX must be in the system command range. ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX); ASSERT(IDM_ABOUTBOX < 0xF000); CMenu* pSysMenu = GetSystemMenu(FALSE); if (pSysMenu != NULL) { CString strAboutMenu; strAboutMenu.LoadString(IDS_ABOUTBOX); if (!strAboutMenu.IsEmpty()) { pSysMenu->AppendMenu(MF_SEPARATOR); pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu); } } // Set the icon for this dialog. The framework does this automatically // when the application's main window is not a dialog SetIcon(m_hIcon, TRUE); SetIcon(m_hIcon, FALSE); // TODO: Add extra initialization here return TRUE; // return TRUE unless you set the focus to a control } void CEmailclientDlg::OnSysCommand(UINT nID, LPARAM lParam) // Set big icon // Set small icon

{ if ((nID & 0xFFF0) == IDM_ABOUTBOX) { CAboutDlg dlgAbout; dlgAbout.DoModal(); } else { CDialog::OnSysCommand(nID, lParam); } } // If you add a minimize button to your dialog, you will need the code below // to draw the icon. For MFC applications using the document/view model, // this is automatically done for you by the framework. void CEmailclientDlg::OnPaint() { if (IsIconic()) { CPaintDC dc(this); // device context for painting SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0); // Center icon in client rectangle int cxIcon = GetSystemMetrics(SM_CXICON); int cyIcon = GetSystemMetrics(SM_CYICON); CRect rect; GetClientRect(&rect); int x = (rect.Width() - cxIcon + 1) / 2; int y = (rect.Height() - cyIcon + 1) / 2; // Draw the icon dc.DrawIcon(x, y, m_hIcon); } else { CDialog::OnPaint(); } }

// The system calls this to obtain the cursor to display while the user drags // the minimized window. HCURSOR CEmailclientDlg::OnQueryDragIcon() { return (HCURSOR) m_hIcon; } void CEmailclientDlg::OnOK() { // TODO: Add extra validation here CDialog::OnOK(); login.ipaddress=m_ipaddress; login.DoModal(); }

emailclientDlg.h : header file


#if !defined(AFX_EMAILCLIENTDLG_H__D6BA526B_3CC1_4771_A228_D5D4F4FF3794__INCLUDED_) #define AFX_EMAILCLIENTDLG_H__D6BA526B_3CC1_4771_A228_D5D4F4FF3794__INCLUDED_ #include "Login.h" #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 ///////////////////////////////////////////////////////////////////////////// // CEmailclientDlg dialog class CEmailclientDlg : public CDialog { // Construction public: CLogin login; CEmailclientDlg(CWnd* pParent = NULL); // Dialog Data //{{AFX_DATA(CEmailclientDlg) enum { IDD = IDD_EMAILCLIENT_DIALOG }; CString m_ipaddress; //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CEmailclientDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); //}}AFX_VIRTUAL // Implementation protected: HICON m_hIcon; // Generated message map functions //{{AFX_MSG(CEmailclientDlg) virtual BOOL OnInitDialog(); afx_msg void OnSysCommand(UINT nID, LPARAM lParam); // DDX/DDV support // standard constructor // Added by ClassView

afx_msg void OnPaint(); afx_msg HCURSOR OnQueryDragIcon(); virtual void OnOK(); //}}AFX_MSG DECLARE_MESSAGE_MAP() }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_EMAILCLIENTDLG_H__D6BA526B_3CC1_4771_A228_D5D4F4FF3794__INCLUDED_)

Inbox.cpp : implementation file

#include "stdafx.h" #include "emailclient.h" #include "Inbox.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CInbox dialog

CInbox::CInbox(CWnd* pParent /*=NULL*/) : CDialog(CInbox::IDD, pParent) { //{{AFX_DATA_INIT(CInbox) //}}AFX_DATA_INIT }

void CInbox::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CInbox) DDX_Control(pDX, IDC_LIST_MESSAGE, m_list); //}}AFX_DATA_MAP }

BEGIN_MESSAGE_MAP(CInbox, CDialog) //{{AFX_MSG_MAP(CInbox) ON_BN_CLICKED(IDC_WRITE_MAIL, OnWriteMail) ON_BN_CLICKED(IDC_LOGOUT, OnLogout) ON_BN_CLICKED(IDC_SHOW, OnShow) ON_BN_CLICKED(IDC_DELETE, OnDelete)

//}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CInbox message handlers BOOL CInbox::OnInitDialog() { CDialog::OnInitDialog(); // TODO: Add extra initialization here client.Create(); client.Connect(ipaddress,4000); CString msg="I"+login; client.Send(msg,msg.GetLength()); char r[1024]; int rlen=client.Receive(r,1023); r[rlen]=NULL; CString fs=r; // AfxMessageBox(fs); client.Close(); CString n,fr,su; // m_list.ResetContent(); int f; while(!fs.IsEmpty()) { int f=fs.Find("^"); n=fs.Left(f); fs=fs.Mid(f+1); f=fs.Find("^"); fr=fs.Left(f); fs=fs.Mid(f+1); f=fs.Find("^"); su=fs.Left(f); fs=fs.Mid(f+1); for(int i=n.GetLength();i<10;i++) n.Insert(i,' '); for(i=fr.GetLength();i<20;i++) fr.Insert(i,' '); msg=n+fr+su; m_list.AddString(msg);

} UpdateData(FALSE); return TRUE; // return TRUE unless you set the focus to a control // EXCEPTION: OCX Property Pages should return FALSE } void CInbox::OnLogout() { CDialog::OnOK(); } void CInbox::OnWriteMail() { w.login=login; w.DoModal(); } void CInbox::OnShow() { client.Create(); client.Connect(ipaddress,4000); int index=m_list.GetCurSel(); CString t; m_list.GetText(index,t); CString no=t.Left(6); no.TrimRight(); CString msg="R"+no; client.Send(msg,msg.GetLength()); char r[1024]; int rlen=client.Receive(r,1023); r[rlen]=NULL; client.Close(); CString fs=r; // AfxMessageBox(fs); int f=fs.Find("^"); from=fs.Left(f); fs=fs.Mid(f+1); f=fs.Find("^"); to=fs.Left(f); fs=fs.Mid(f+1);

f=fs.Find("^"); s=fs.Left(f); mess=fs.Mid(f+1); read.m_from=from; read.m_to=to; read.m_sub=s; read.m_msg=mess; read.DoModal(); } void CInbox::OnDelete() { // TODO: Add your control notification handler code here client.Create(); client.Connect(ipaddress,4000); int index=m_list.GetCurSel(); CString t; m_list.GetText(index,t); CString no=t.Left(6); no.TrimRight(); CString msg="D"+no+"^"+login; client.Send(msg,msg.GetLength()); char r[1024]; int rlen=client.Receive(r,1023); r[rlen]=NULL; CString fs=r; // AfxMessageBox(fs); client.Close(); CString n,fr,su; m_list.ResetContent(); int f; while(!fs.IsEmpty()) { int f=fs.Find("^"); n=fs.Left(f); fs=fs.Mid(f+1); f=fs.Find("^"); fr=fs.Left(f); fs=fs.Mid(f+1); f=fs.Find("^"); su=fs.Left(f);

fs=fs.Mid(f+1); for(int i=n.GetLength();i<10;i++) n.Insert(i,' '); for(i=fr.GetLength();i<20;i++) fr.Insert(i,' '); msg=n+fr+su; m_list.AddString(msg); } // } UpdateData(FALSE);

Inbox.h : header file


#if !defined(AFX_INBOX_H__AD20B694_8D59_4019_95E0_8F97096DC335__INCLUDED_) #define AFX_INBOX_H__AD20B694_8D59_4019_95E0_8F97096DC335__INCLUDED_ // Added by ClassView #include "Writemail.h" #include "Readmail.h" #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 // Inbox.h : header file // ///////////////////////////////////////////////////////////////////////////// // CInbox dialog class CInbox : public CDialog { // Construction public: CString ipaddress; CReadmail read; CString mess; CString s; CString to; CString from; CWritemail w; CString login; CInbox(CWnd* pParent = NULL); // standard constructor // Dialog Data //{{AFX_DATA(CInbox) enum { IDD = IDD_INBOX }; CListBox //}}AFX_DATA m_list; // Added by ClassView

// Overrides

// ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CInbox) public: protected: virtual void DoDataExchange(CDataExchange* pDX); //}}AFX_VIRTUAL // Implementation protected: // Generated message map functions //{{AFX_MSG(CInbox) virtual BOOL OnInitDialog(); afx_msg void OnWriteMail(); afx_msg void OnLogout(); afx_msg void OnShow(); afx_msg void OnDelete(); //}}AFX_MSG DECLARE_MESSAGE_MAP() private: CSocket client; }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_INBOX_H__AD20B694_8D59_4019_95E0_8F97096DC335__INCLUDED_) // DDX/DDV support

Login.cpp : implementation file


#include "stdafx.h" #include "emailclient.h" #include "Login.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CLogin dialog

CLogin::CLogin(CWnd* pParent /*=NULL*/) : CDialog(CLogin::IDD, pParent) { //{{AFX_DATA_INIT(CLogin) m_login = _T(""); m_password = _T(""); //}}AFX_DATA_INIT }

void CLogin::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CLogin) DDX_Text(pDX, IDC_LOGIN, m_login); DDX_Text(pDX, IDC_PASSWORD, m_password); //}}AFX_DATA_MAP }

BEGIN_MESSAGE_MAP(CLogin, CDialog) //{{AFX_MSG_MAP(CLogin) //}}AFX_MSG_MAP END_MESSAGE_MAP()

///////////////////////////////////////////////////////////////////////////// // CLogin message handlers void CLogin::OnOK() { // TODO: Add extra validation here client.Create(); client.Connect(ipaddress,4000); UpdateData(TRUE); CString login_packet="M:"+m_login+":"+m_password; client.Send(login_packet,login_packet.GetLength()); char s[6]; int slen=client.Receive(s,5); s[slen]=NULL; CString status=s; if (status=="OK") { inbox.login=m_login; inbox.ipaddress=ipaddress; inbox.DoModal(); } if(status=="NOTOK") AfxMessageBox("Your Login name or Password is incorrect. Please try Again !!!"); client.Close(); // } CDialog::OnOK();

Login.h : header file


#if !defined(AFX_LOGIN_H__8508B0BA_14DF_4E90_8DAB_CFC630FE658C__INCLUDED_) #define AFX_LOGIN_H__8508B0BA_14DF_4E90_8DAB_CFC630FE658C__INCLUDED_ #include "Inbox.h" #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 // Login.h : header file // ///////////////////////////////////////////////////////////////////////////// // CLogin dialog class CLogin : public CDialog { // Construction public: CString ipaddress; CInbox inbox; CLogin(CWnd* pParent = NULL); // standard constructor // Dialog Data //{{AFX_DATA(CLogin) enum { IDD = IDD_LOGIN }; CString m_login; CString m_password; //}}AFX_DATA // Added by ClassView

// Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CLogin) protected: virtual void DoDataExchange(CDataExchange* pDX); //}}AFX_VIRTUAL // Implementation // DDX/DDV support

protected: // Generated message map functions //{{AFX_MSG(CLogin) virtual void OnOK(); //}}AFX_MSG DECLARE_MESSAGE_MAP() private: CSocket client; }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_LOGIN_H__8508B0BA_14DF_4E90_8DAB_CFC630FE658C__INCLUDED_)

Readmail.cpp : implementation file


#include "stdafx.h" #include "emailclient.h" #include "Readmail.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CReadmail dialog

CReadmail::CReadmail(CWnd* pParent /*=NULL*/) : CDialog(CReadmail::IDD, pParent) { //{{AFX_DATA_INIT(CReadmail) m_from = _T(""); m_to = _T(""); m_sub = _T(""); m_msg = _T(""); //}}AFX_DATA_INIT }

void CReadmail::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CReadmail) DDX_Text(pDX, IDC_EDIT1, m_from); DDX_Text(pDX, IDC_EDIT2, m_to); DDX_Text(pDX, IDC_EDIT3, m_sub); DDX_Text(pDX, IDC_EDIT4, m_msg); //}}AFX_DATA_MAP }

BEGIN_MESSAGE_MAP(CReadmail, CDialog) //{{AFX_MSG_MAP(CReadmail) // NOTE: the ClassWizard will add message map macros here //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CReadmail message handlers

Readmail.h : header file


#if !defined(AFX_READMAIL_H__7C1AD71B_9A53_4CAE_832D_F6F04F9AB0CE__INCLUDED_) #define AFX_READMAIL_H__7C1AD71B_9A53_4CAE_832D_F6F04F9AB0CE__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 // Readmail.h : header file // ///////////////////////////////////////////////////////////////////////////// // CReadmail dialog class CReadmail : public CDialog { // Construction public: CReadmail(CWnd* pParent = NULL); // standard constructor // Dialog Data //{{AFX_DATA(CReadmail) enum { IDD = IDD_Readmail }; CString m_from; CString m_to; CString m_sub; CString m_msg; //}}AFX_DATA

// Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CReadmail) protected: virtual void DoDataExchange(CDataExchange* pDX); //}}AFX_VIRTUAL // Implementation protected: // DDX/DDV support

// Generated message map functions //{{AFX_MSG(CReadmail) // NOTE: the ClassWizard will add member functions here //}}AFX_MSG DECLARE_MESSAGE_MAP() }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_READMAIL_H__7C1AD71B_9A53_4CAE_832D_F6F04F9AB0CE__INCLUDED_)

stdafx.cpp
// stdafx.cpp : source file that includes just the standard includes // // emailclient.pch will be the pre-compiled header stdafx.obj will contain the pre-compiled type information

#include "stdafx.h"

stdafx.h
// stdafx.h : include file for standard system include files, // or project specific include files that are used frequently, but // // #if !defined(AFX_STDAFX_H__9A98610D_B44C_4BE7_B482_25C6290DA63D__INCLUDED_) #define AFX_STDAFX_H__9A98610D_B44C_4BE7_B482_25C6290DA63D__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #define VC_EXTRALEAN #include <afxwin.h> #include <afxext.h> #include <afxdisp.h> #include <afxdtctl.h> #include <afxcmn.h> // Exclude rarely-used stuff from Windows headers are changed infrequently

// MFC core and standard components // MFC extensions // MFC Automation classes // MFC support for Internet Explorer 4 Common Controls // MFC support for Windows Common Controls

#ifndef _AFX_NO_AFXCMN_SUPPORT #endif // _AFX_NO_AFXCMN_SUPPORT #include <afxsock.h> //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_STDAFX_H__9A98610D_B44C_4BE7_B482_25C6290DA63D__INCLUDED_) // MFC socket extensions

Writemail.cpp : implementation file


#include "stdafx.h" #include "emailclient.h" #include "Writemail.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CWritemail dialog

CWritemail::CWritemail(CWnd* pParent /*=NULL*/) : CDialog(CWritemail::IDD, pParent) { //{{AFX_DATA_INIT(CWritemail) m_to = _T(""); m_subject = _T(""); m_msg = _T(""); //}}AFX_DATA_INIT }

void CWritemail::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CWritemail) DDX_Text(pDX, IDC_TO, m_to); DDX_Text(pDX, IDC_SUBJECT, m_subject); DDX_Text(pDX, IDC_MESSAGE, m_msg); //}}AFX_DATA_MAP }

BEGIN_MESSAGE_MAP(CWritemail, CDialog) //{{AFX_MSG_MAP(CWritemail)

ON_BN_CLICKED(IDC_SEND, OnSend) ON_BN_CLICKED(IDC_BUTTON2, OnClose) //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CWritemail message handlers void CWritemail::OnSend() { // TODO: Add your control notification handler code he client.Create(); client.Connect("127.0.0.1",4000); UpdateData(TRUE); CString msg="S"+login+"^"+m_to+"^"+m_subject+"^"+m_msg; client.Send(msg,msg.GetLength()); client.Close(); } void CWritemail::OnClose() { // TODO: Add your control notification handler code here CDialog::OnOK(); }

Writemail.h : header file


#if !defined(AFX_WRITEMAIL_H__890CB3FC_DC54_4FFE_A92F_485CE86B6A78__INCLUDED_) #define AFX_WRITEMAIL_H__890CB3FC_DC54_4FFE_A92F_485CE86B6A78__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 // Writemail.h : header file // ///////////////////////////////////////////////////////////////////////////// // CWritemail dialog class CWritemail : public CDialog { // Construction public: CSocket client; CString login; CWritemail(CWnd* pParent = NULL); // standard constructor // Dialog Data //{{AFX_DATA(CWritemail) enum { IDD = IDD_COMPOSE }; CString m_to; CString m_subject; CString m_msg; //}}AFX_DATA

// Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CWritemail) protected: virtual void DoDataExchange(CDataExchange* pDX); //}}AFX_VIRTUAL // Implementation protected: // DDX/DDV support

// Generated message map functions //{{AFX_MSG(CWritemail) afx_msg void OnSend(); afx_msg void OnClose(); //}}AFX_MSG DECLARE_MESSAGE_MAP() }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_WRITEMAIL_H__890CB3FC_DC54_4FFE_A92F_485CE86B6A78__INCLUDED_)