KR20030033803A - Method and System for transporting email based on peer-to-peer technology - Google Patents

Abstract

PURPOSE: A system for forwarding an E-mail based on a peer-to-peer and a method thereof are provided to transmit a large quantity of E-mails in a short time at low cost without extending an E-mail transmission server and a network band width additionally by utilizing network resources of idle PCs distributed in the Internet. CONSTITUTION: A large quantity mail message is prepared(601). A P2P mail transmission server or a distributor triggers a job to a P2P mail transmission peer(602). A P2P mail transmission peer connects to the server and downloads E-mail information of mail message receivers(603). The P2P mail transmission peer connects to the server and downloads a mail message(604). The P2P mail transmission peer transmits a mail message, which is downloaded from the server, to mail message receivers(605). The P2P mail transmission peer reports a mail message transmission result to the server(606).

Description

Peer-to-peer based email sending system and its method {Method and System for transporting email based on peer-to-peer technology}

The present invention relates to an email sending system and a method thereof. Email sending systems can be easily described by describing key components. An email message is information that an internet user wants to send to the other party. Messages can contain binary files and other parts that can be attached to the message. The message is sent from the MUA. MUAs can also be used to read messages from others.

The key components of the Internet e-mail sending system are as follows.

-MUA (Mail User Agent): Client program used by users to send and receive e-mail. The MUA may be a program or a script that emulates the typical MUA's behavior of sending and receiving e-mail.

MTA (Mail Transfer Agent): A server program that transfers e-mail from one computer on the Internet to another (mail server).

MDA (Mail Delivery Agent): A program used by the MTA to write messages to the user's mailbox.

Mail Retrival Agent (MRA): A service that retrieves a message from a mailbox on a remote server to a user's MUA.

For example, an e-mail message is sent from the MUA to the MTA. This is known as the sending MTA. The sending MTA sends the message to one or more MTAs until the message reaches its destination, that is, the receiving MTA. The receiving MTA actually has an account for the recipient of the message. The receiving MTA sends a message to the MDA. The MDA writes a message to the recipient's mailbox, which is usually a file in the file system. The recipient uses another MUA to read the message and retrieves the message from the mailbox. MUA also sorts, sorts, or stores mail messages.

When the recipient is using a mail server rather than his local computer, the mailbox must be read some distance away. In this case, we use what is called an MRA. This is not a standard term but represents a useful concept.

The MUA uses the Internet's Simple Mail Transfer Protocol (SMTP) to send mail to the MTA. If there is a binary attachment, it uses MIME. The MTA also uses SMTP between the MTAs. MRAs commonly use the Internet's Post Office Protocol (POP), more recently using the Internet Message Access Protocol (IMAP), or the older protocol called Unix to Unix Copy (UUCP).

The conventional e-mail sending system uses a technology to prevent the overload caused by sending by extending the servers in charge of the delivery MTA and TCP MDA in parallel in order to send a large amount of e-mail in a short time. In addition, by expanding the sending server in parallel, the number of emails that can be sent per unit time increases. This results in a high cost system that uses a lot of network bandwidth and has to pay a double cost to further expand the network bandwidth.

The following is a description of the peer-to-peer (P2P for short) technology used in the present invention. In the current trend of peer-to-peer applications that communicate as peers that share and receive information, such as Napster, Gnutella, or 'Sori Sea', these applications tend to be used by users connected to large networks. It is a means to utilize.

The most important factor in writing almost any type of application is communication. Any application is of great value when it is well distributed on the Internet or intranet and can flexibly interact with other resources. Currently, the most commonly used model for communication over the Internet is client / server, which responds to requests from clients and clients that know how to request and post information to the server. There is a server that knows how to do this. A common example of this model is a browser connected to a web server. In other words, a browser sends a request to a web server, and the server listens to the request and sends a response or sends information (usually in the form of a web page). . In this model, the web server cannot arbitrarily contact the browser, and "conversation" is always initiated on the client side.

Peer-to-peer applications differ from the typical client / server model in that they are involved in both client and server roles. In other words, it can receive information requests from other servers and at the same time act as a server to respond to requests for information from other clients. This approach increases the level of value that can be added to each node of the network, because it not only derives information from the source, but can also share information with other sources. The following are the essential features required to define a typical peer-to-peer application.

The application must be able to identify other applications that want to share information. Historically, we've used a way to find these peers by registering all the applications we want to share with a central server that's included in the list, and providing this list every time a new application connects to the network. However, other methods may be used, such as network broadcasting or search algorithms.

After finding these peers, the application checks for the desired content. Content requests often come from users, but rather than specific requests made by users on that computer, the peer-to-peer application can run itself to perform queries and to process requests from other networks as a result. It is.

The following is a description of the four application models for peer-to-peer implementations.

1. Pure Peer-to-Peer Implementation Model

Pure peer-to-peer applications do not have a central server equivalent. Pure peer-to-peer applications directly search for other peers on the network and send and receive content through each interaction. This type of strength is that you do not have to rely on one server to register its location so that other peers can find it. In addition, due to the absence of a central search server, there may be a problem that the number of clients that can be searched is relatively small, thereby limiting the range of applications. In this scenario, the peer can use the information from the local configuration schema to retrieve the client (for example, using a configuration item that indicates who is connected), or use discovery techniques such as network broadcasting and IP multicast. You can also find other peers.

The use of IP multicast may be problematic in that it is not widely deployed on the Internet, but it is very useful in intranet environments where the control of the network is relatively well maintained and the infrastructure required for multicast exists. can see. Pure peer-to-peer is built on the Internet when searching for peers using a schema other than multicast. In this case, the application will use a different schema, which is a well-known node where each peer knows one or more other peers and shares this knowledge with other peers, loosely connecting to multiple nodes. An approach is possible.

2. Peer-to-peer implementation model using a single search server

This architecture works almost identically to a pure peer-to-peer architecture, except that it uses a central server to find other peers. In this model, the application is aware of the central server at startup (or login time). Peer applications use this server to download lists of other peers participating in the network and use them for content queries. If you need content, browse through the list and check each peer individually.

In many cases it is much easier to configure this solution range better than the pure peer-to-peer option. This is because you can avoid multiple search problems by requiring only one request from the central server. Although it is possible to configure the scope of a pure peer-to-peer solution well, relying on one server for basic tasks (eg search) can provide high scalability at low cost in terms of development time. However, this approach depends on the availability of a central server. In other words, if the central server is unavailable, the peer-to-peer application will not be able to find another peer.

In addition, requesting content from individual peers can be expensive in terms of network resources. Of course, this may not be a big deal when the number of peers interacting over the network is small, but if the application is written for use on the Internet or in a large corporate environment, this can be a serious problem.

3. Peer-to-Peer Implementation Model Using Search and Lookup Server

This model extends the search server to include content retrieval services. In this case, the peer application not only registers with the search server, but also uploads the content list at regular intervals. When an application finds specific content, it queries a central server rather than sending a query to each client. The central server provides a list of clients holding the requested content and peer applications can contact these clients directly to retrieve the content.

This approach is more scalable than the previous option because it reduces the number of queries that appear on the network (one of the scarce resources). However, these savings incur server costs. Currently, servers are more involved in the content sharing process, and they use resources considerably at the request of peers.

4. P2P Implementation Model Using Search, Inquiry, and Content Server

To show that you can actually return to its original state, you can choose to have the system designed so that peers can upload content to the server. This approach is an effective client / server model in that no more peer-to-peer contact is made for content. Each peer registers with the server (as needed), queries the server to verify the information, and receives the desired content from the server. The problem is that the server is often the bottleneck when downloading content from all clients and is easily overwhelmed by peers.

For the P2P implementation model using search, inquiry, and content server, a peer-to-peer application for sending an email can be considered. Suppose your application supports up to 10,000 peers, each holding 1000 emails to be sent from the server and retaining email information data. Even if the number of emails that can be sent to a peer is limited to 1000, a total of 10 million emails can be sent. Even if the volume of e-mail to be sent continues to increase, P2P is less expensive and less susceptible to serious bottlenecks and network stability issues than servers sending mail directly.

The present invention is based on the P2P implementation model using search, inquiry, and content server, P2P-based email sending system that sends a large amount of email in a short time at a lower cost without the expansion of email sending server and expansion of network bandwidth. To provide.

An object of the present invention is to provide a P2P-based email sending system that sends a large amount of email in a short time at a lower cost without further expansion of the email sending server and expansion of network bandwidth by utilizing network resources of idle PCs distributed on the Internet. I would like to.

Figure 1a is a schematic diagram showing the overall configuration of the Internet mail transmission / reception system, Figure 1b is a schematic diagram showing the overall configuration of the existing mass mail sending system and the flow of mail sent and received using this system It is also.

FIG. 2 is a schematic diagram of three application models of a peer-to-peer implementation, FIG. 2A is a pure peer-to-peer implementation model, FIG. 2B is a peer-to-peer implementation model using a single search server, and FIG. 2c is a diagram illustrating a P2P implementation model using a search, inquiry, and content server.

Figure 3 is a schematic diagram showing the overall configuration of the P2P-based mass mail sending system and the flow of mail sent and received using the system.

4 is a diagram illustrating the configuration of a P2P mail sending server classified into modules.

FIG. 5A is a diagram illustrating the configuration of P2P mail sending peers classified by module. FIG. 5B is an interface hierarchy diagram made to easily utilize the peer function in an application program.

6 is a flowchart illustrating the entire flow chart of the P2P based mass mail sending system.

A component of a P2P-based email sending system for achieving the above object of the present invention is characterized by consisting of a P2P mail sending server and a P2P mail sending peer, and the sending method consists of the following six steps. (See Figure 6)

First, create a mass mailing message. (601)

Second, the P2P mail sending server or distributor triggers the action on the P2P mail sending peer. (602)

Third, the P2P mail sending peer connects to the server and downloads the email information of the mail message recipients. (603)

Fourth, the P2P mail sending peer connects to the server and downloads the mail message. (604)

Fifth, the P2P mail sending peer sends the mail message downloaded from the server to the mail message receivers. (605)

Sixth, the P2P mail sending peer reports the mail message sending result to the server. (606)

Hereinafter, with reference to the accompanying drawings will be described an embodiment of a mass email sending method according to the present invention.

1A and 1B are schematic diagrams to help understand that there are expensive components of the existing Internet delivery system.

Figure 1a is a simplified view showing the overall configuration of the simplified Internet mail transmission / reception system, 'mail sender' 101, 'sending MUA' 102, 'SMTP' (103, 107), 'delivery MTA' (104), 'system call' (105, 109), 'TCP MDA' (106), 'receive MTA' (108), 'local MDA' (110), 'write to mailbox' (111), 'mailbox' (112), 'MRA' (113), 'receive MUA' (114), 'mail recipient' (115). Each of the above components is connected to each other by a computer network.

MUA 102 attempting to send a message uses Simple Mail Transfer Protocol (SMTP) protocols 103 and 107 to communicate with MTA 104. The MUA sends the message directly to the MTA handling the mail for the recipient, or to the local MTA that will forward the message. The computer that receives the message is an MTA, referred to herein as a receiving MTA 108. The receipt of the mail by the MTA does not mean that the user has read the mail, but merely that it has been delivered to the user's mailbox. There is no inherent capability to notify the sender whether or not the message has been received inside SMTP. There is only a notification that the delivery failed.

The MTA does not deliver the message itself. Just prepare the message to take the next exaggeration on the same travel route as another type of network. The receiving MTA calls an external program to deliver a message on the same physical computer. This program is known as MDA 110.

The MDA is used to write a message to the user's mailbox (111), deliver it to another MTA, or deliver it to another mail system. A separate program is typically used to perform each of these functions. The MTA usually has an MDA for local delivery (directly written to the user's mailbox) and another MDA 106 for TCP-based socket delivery.

Local delivery writes a message to a file mailbox. The mailbox is on the MDA's file system and does not make final delivery to the user. If the user does not have direct access to his or her mailbox, the user's MUA will use the MRA 113 to access the mailbox remotely.

If the message is intended for a user who does not have an account on the local system, message delivery to another MTA occurs. In this case, the recipient's address is parsed to determine the destination domain, and the Internet Domain Name System (DNS) is used to find the destination MTA. The MDA will then be called which handles the appropriate delivery mechanism by the MTA to deliver the message to the destination MTA.

FIG. 1B briefly shows the overall configuration of the existing mass mail sending system and the flow of mail transmitted and received using the system, and is composed of a 'mail sending server' 151 and a mail receiving server 158.

The mail sending server 151 is composed of a sending MUA 152, a forwarding MTA 153, a TCP MDA 154, and a mail receiving server 157 via the Internet 156 using SMTP 155, 157. Deliver mail messages to The mail receiving server 158 is composed of a receiving MTA 159, a local MDA 160, and a mailbox 161. The mail receiver 164 receives a mail using the receiving MUA 163.

However, in order to send a large amount of e-mail in a short time, the mail sending server 151 uses a technology to prevent the overload caused by sending by extending the servers in charge of the delivery MTA (153) and TCP MDA (154) in parallel. . In addition, as the number of e-mails to be sent per unit time increases due to the expanded server, the network bandwidth 155 is used more, which is a high cost system that needs to double the network bandwidth.

FIG. 2 is a schematic diagram of four application models of a peer-to-peer implementation, FIG. 2A is a 'pure peer-to-peer implementation model', and FIG. 2B is a 'peer-to-peer implementation using a single search server. 2C is a block diagram illustrating a P2P implementation model using a search, inquiry, and content server.

Figure 2a is a 'pure peer-to-peer implementation model' configuration diagram, pure peer-to-peer application does not correspond to a central server. Pure peer-to-peer applications directly search for other peers 201, 202, and 203 on the network to send and receive content through interaction 204, respectively.

FIG. 2B is a 'peer-to-peer implementation model using a single search server' configuration, which works almost identically to a pure peer-to-peer architecture, but uses the central server 211 to find other peers. The difference is that it uses. In this model, the application is aware of the central server at startup (or login time). The peer application will use this server to download a list of other peers 212, 213, 214 participating in the network and use it in the content query 215. If content is needed, the list is browsed and each peer is individually contacted 216 to confirm.

FIG. 2C is a schematic diagram of a P2P implementation model using a search, query, and content server to show content from the peers 222, 223, and 224 to the server 221 to show that it can actually be returned to its original state. You can choose to have the system designed for upload. This approach is an effective client / server model in that no more peer-to-peer contact is made for content. Each peer registers using the server (as needed), queries 225 the server to verify the information, and receives 225 the desired content from the server.

3 is a schematic diagram showing the overall configuration of the P2P-based mass mailing system and the flow of mails transmitted and received using the system. The P2P mail sending server 301 and the P2P mail sending peer 305 are shown in FIG. , 'Mail receiving server' (312).

'P2P mail sending server' 301 provides a search, inquiry, content providing service for sending mail. P2P mail sending peer 305 is composed of P2P manager 306, forwarding MTA (307), TCP MDA (308), and P2P mail sending server and mail message inquiry for P2P mail sending over the Internet (303), Interactions 302 and 304, such as e-mail recipient lookup, are performed. A general real time transaction protocol such as HTTP is suitable for the preferred embodiment of this interaction.

The email message is delivered from the 'P2P mail sending peer' 305 to the mail receiving server 312 via the Internet 310, in which general SMTP protocols 309 and 311 are used. The improvement compared to the conventional mail sending system is that the mail MTA 307 and the TCP MDA 308, which are parallel expandable parts of the mail sending server, are mounted on the P2P mail sending peer 305, which is distributed idle on the Internet. An improvement is that it downloads and installs on one PC to utilize the network resources of the individual PC. The P2P mail sending server 301 cooperates with the P2P manager 306 302 and 304 to perform the sending MUA role.

4 is a block diagram illustrating the configuration of a P2P mail sending server by module, and includes a 'mail message production DB' 401, a 'mail message distributor member information DB' 402, and a 'mail message recipient email information DB'. 403, control module 405, mail message input and modification module 404, mail message distributor member information input and modification module 406, P2P mail sending peer application download service module 407 ), 'P2P Send Mail Peer Presence Service Module' (408), 'P2P Send Mail Peer Trigger Service Module' (409), 'Mail Message Recipient Email Information Download Service Module' (410), 'Mail Message Download Service Module' ( 411), 'advertisement mail sending result management module' (412).

The 'mail message production DB' 401 is a DB for storing mail messages, and is managed through the 'mail message input and modification module' 404. The preferred embodiment can be made accessible by a general URL at http://www.xmlschema.net/mail/mailmsg.xsl and then provided for easy download by a peer-to-peer mailing peer.

The 'Mail Message Distributor Member Information DB' 402 is a DB in which personal information of a Mail Message Distributor whose member PC is registered to operate as a peer is registered. The 'Mail Message Distributor Member Information Input and Modification Module' (406) It is managed through). In the preferred embodiment, an individual's name, e-mail address, e-mail address of recipient, etc. to which he or she is responsible for distribution are registered.

The 'mail message recipient email information DB' 403 stores email related information of a person who will receive a mail. Examples of preferred embodiments include information such as the recipient's email address, mail reception results, mail open results, mail click results, and the like.

`` Download service of P2P mail sending peer application '' (407) is a service that allows the application to be installed to act as a P2P mail sending peer, and the preferred embodiment is based on Microsoft's ActivX technology. Alternatively, you can take advantage of automated download and installation technology right from the web page and download it as a standalone application.

The existing mail sending server technology was developed on the assumption that servers related to mail sending have a fixed IP address and that the mail sending service is already installed and is always available. However, P2P-based technology has been developed on the assumption that each PC distributed on the Internet has a floating IP address and may not have a mail sending service installed. The advantage is that if there is a large amount of mail to send, the advantage of being able to send mail at a high speed without the cost of sending additional mail using idle PC resources existing on the Internet at any time.

In order to utilize the P2P technology, the P2P mail sending server must manage the floating IP address of the P2P mail sending peer. In other words, in order to utilize the resources of the personal PC, the peer's network resources must be registered in the server to utilize the network resources of the peer, and in P2P technology, the presence (presence) is managed 408. However, if there is a way for the user to activate the program directly, the floating IP is transmitted to the server when it is activated and the application can be terminated when the execution is completed.

The P2P mail sending peer trigger service module 409 is a module for notifying the P2P mail sending peer that there is mail to be sent by the P2P server. In a preferred embodiment, when a mail is sent to a distributor member as an email and the contents of the mail are clicked on, the P2P mail sending peer module is activated to send the mail. It can also be triggered automatically by signaling its peer port if the server knows the registered floating IP address when the peer-to-peer peer is started.

The 'mail message receiver email information download service module' 410 and the 'mail message download service module' 411 are service modules for downloading information stored in a server. Examples of preferred embodiments using the HTTP protocol are as follows. Jinwoo@datawave.co.kr, registered as an e-mail distributor, requests the server to download information and the result is downloaded. The meaning of the downloaded contents is that "Park Jin-Woo" sends mail to "Jung Seung-hoon", "Jeon Hye-won", "Jung Yong-ho", and mail messages are sent to http://www.xmlschema.net/mail/mailmsg.xsl This is an example of the location.

-Example

GET /download_p2p_email_info?distributor=jinwoo@datawave.co.kr

-Example of downloaded information:

<mailpeer xmlns: mp = "http://www.xmlschema.net/mail/1.0">

<mp: template>

<mp: from address = "jinwoo@datawave.com" name = "Park Jin-woo" />

<mp: reply address = "webmaster@datawave.co.kr" name = "admin" />

<mp: subject> Chrysanthemum flower fragrance will be mailed October 12. </ mp: subject>

<mp: body transform = http: //www.xmlschema.net/mail/mailmsg.xsl/>

</ mp: template>

<mp: mail id = "1001" name = "정승훈" email = "hun@data.com"> </ mp: mail>

<mp: mail id = "1002" name = "전혜원" email = "won@data.com"> </ mp: mail>

<mp: mail id = "1003" name = "Jung Yong Ho" email = "ho@data.com"> </ mp: mail>

...

</ mp: mail>

</ mailpeer>

FIG. 5A is a diagram illustrating the configuration of P2P mail sending peers classified by module. The downloaded mail message DB 501, the downloaded mail message recipient email information DB 502, and the control module 504 are shown in FIG. , "Mail message download module" (403), "mail message recipient download module" (505), "P2P mail sending peer presence module" (506), "P2P mail sending peer trigger module" (507), "delivery MTA module" 508, a TCP MDA module 509, and a mail sending result upload module 510.

'Downloaded mail message DB' 501, 'Downloaded mail message recipient email information DB' 502 refers to information transmitted from the server in the above embodiment, 'mail message distributor member information DB' 402, ' The mail message recipient email information DB '403 is provided through the mail message recipient email information download service module 410 and the mail message download service module 411.

The P2P mail sending peer presence module 506 is required to register the peer's floating IP address with the server so that the server can inform the peer of a particular event. In the preferred embodiment, the peer's floating IP address, peer's distributor member ID, and the like are registered with the server. However, the presence module may be omitted if the distributor activates the peer-to-peer peer directly.

'P2P mail sending peer trigger module' 507 is a module that provides signaling to enable a P2P mail sending peer module on a distributor's PC. In a preferred embodiment, a P2P server may send a signal directly to a peer, or an email distributor You can also activate the module by clicking the mouse's activation button directly. In the latter case, an email distribution signal button can be delivered to the distributor via email, or the distributor can log in to the web service and activate the module by clicking the mouse.

A preferred embodiment of the property interface of the delivery MTA 508 and TCP MDA 509 module of a P2P mail sending peer is as follows.

BodyText: Contains the email message to send. Example: Mailer.BodyText = "Hi, thank you for your message."

ContentType: Used to set the content type of the BodyText. If the email message is of type HTML, Mailer.ContentType = "text / html".

Encoding-Describes how to encode an attached file. The default is to use the MIME or UUEncoded method.

FromName: The name of the mail sender. Yes, Mailer.FromName = "Hong Gil Dong"

FromAddress: The email address of the mail sender. E.g. Mailer.FromAddress = "hong@korea.com"

RemoteHost: Remote SMTP host to relay mail. This host can be the SMTP server of your local ISP or the SMTP host that will receive mail. For example, Mailer.RemoteHost = "mailhost.myisp.net"

ReplyTo: Used when the e-mail address to receive the reply is different from the sender.

-Response: Contains an error message that occurred when sending an email.

Subject: Subject of the email message. Yes, Mailer.Subject = "Long time!"

A preferred embodiment of the method interface of the delivery MTA 508 and TCP MDA 509 module of a P2P mail sending peer is as follows.

SendMail: Send mail.

AddRecipient: adds the mail recipient email address.

ClearRecipients Clears all mail recipient email addresses.

-AddCC: Add email reference recipient email address.

ClearCCs Clears all email reference recipient email addresses.

AddAttachment: adds an attachment.

ClearAttachments Deletes attachments.

ClearBodyText Deletes all mail messages.

ClearExtraHeaders: Clears X-Headers set via AddExtraHeaders.

AddExtraHeader Adds X-Headers to the email envelop.

GetBodyTextFromFile Loads the contents of an email message from a file.

EncodeHeader: Encodes the title in RFC1522 format to support 8-bit characters.

5b is an interface hierarchical diagram which enables an application program to easily utilize the function of the peer. The computer application program 521, P2P-based mail sending peer interface 522, and P2P-based mail sending peer engine 523, respectively.

This can be easily done by providing a COM interface that can easily call API (Application Programming Interface) of P2P-based mail sending peer engine in existing applications.

One technology that makes module interfaces easy in applications is Microsoft's COM. COM stands for Component Object Model. COM is one of the features of Microsoft Windows that allows object-oriented programming with compiled and linked binary code, and object-based binaries that allow interactions between objects through predefined routines called interfaces. It's a standard defined by Microsoft. This means that there is an interface between objects (including the application), which allows sharing between objects. In distributed environment (Corba, COM) programming, there are standard rules that define interfaces and rules that apply them (such as type libraries).

This is an example of implementing a mail sending script in Visual Basic using a module interface in a mail sending peer.

Set Mailer = Server.CreateObject ("P2P.Mailer")

Mailer.FromName = "Egisub"

Mailer.FromAddress = "leeks@datawave.com"

Mailer.RemoteHost = "mail.datawave.co.kr"

Mailer.AddRecipient "hun@address.com"

Mailer.Subject = "This is the mail subject."

Mailer.ContentType = "text / html"

Mailer.BodyText = "<html> <body> Here's some info </ body> </ html>"

if Mailer.SendMail then

Response.Write "Mail sent ..."

else

Response.Write "Mail failure. Check mail host server ..."

Response.Write "<p>" & Mailer.Response

end if

6 is a flowchart illustrating the entire flow chart of a P2P based mass mail sending system.

First, create a mass mailing message. (601)

Second, the P2P mail sending server or distributor triggers the action on the P2P mail sending peer. (602)

Third, the P2P mail sending peer connects to the server and downloads the email information of the mail message recipients. (603)

Fourth, the P2P mail sending peer connects to the server and downloads the mail message. (604)

Fifth, the P2P mail sending peer sends the mail message downloaded from the server to the mail message receivers. (605)

Sixth, the P2P mail sending peer reports the mail message sending result to the server. (606)

The advantage of the P2P-based mail delivery method is that most or all of the computing resources needed to run the application can be obtained from the peers. P2P-based mail delivery can provide significant benefits, including:

Improved performance and price / performance: Distributing resources or computations across the network reduces bottlenecks and transmission delays due to the messages and data being delivered. P2P-based mail sending methods distribute the load of bandwidth across the network's “edges” over a huge number of peers. Because the P2P applications run on the desktops, each with the best price / performance ratio, the overall system also improves performance. The price / performance of applications that rely on “free” computing resources from under-used desktops is much better.

Scalability and Organic Growth: Scalability allows the system to cope with the increased workload, while preventing the random increase in cost per email sending transaction. You can set up and scale organically your P2P applications to deliver tens of millions of emails in a short amount of time with little or no resources added to your performance management and infrastructure investments.

Fault Tolerance and Availability: With the exception of the central server, P2P networks will function properly even when some nodes are unavailable. Each node allows the network to operate with other nodes available autonomously.

Claims (7)

The component of the P2P-based email sending system is composed of a P2P mail sending server and a P2P mail sending peer. First, create a mail message for bulk sending, Second, the P2P mail sending server or distributor triggers an action to the P2P mail sending peer, Thirdly, the peer-to-peer mail sending peer connects to the peer-to-peer mail sending server and downloads the email information of the mail message recipients; Fourthly, the P2P mail sending peer connects to the P2P mail sending server and downloads the mail message; Fifth, the P2P mail sending peer sends the mail message downloaded from the P2P mail sending server to the mail message recipients, Sixth, the P2P-based e-mail sending method comprising the step of reporting the mail message sending result to the P2P mail sending server by the P2P mail sending peer. The method of claim 1, The P2P mail sending server or distributor triggers the action to the P2P mail sending peer. The P2P mail sending peer module, which is developed using a component object model technology such as ActiveX, is installed on the email message to the distributor. The distributor checks his mailbox and opens the mail containing the distribution message and clicks the Activate button to activate the 'P2P mail sending peer' on his PC. The method of claim 1, P2P mail sending server or distributor is a method of triggering actions on P2P mail sending peer. The P2P mail sending peer module developed using component object model technology such as ActiveX is installed on the web service page so that the distributor can How to activate 'P2P mail sending peer' on your PC by checking the email sending trigger on the page, opening the webpage and clicking the Activate button. The method of claim 1, P2P mail sending server or distributor is a method of triggering actions on P2P mail sending peer. The P2P mail sending peer module developed using component object model technology such as ActiveX is installed on a separate application so that the distributor can To activate the 'P2P mail sending peer' that is always running on the server without the distributor's input The method of claim 1, The P2P mail sending peer connects to the P2P mail sending server and downloads the email information and mail messages of the mail message recipients. The P2P mail sending peer downloads the recipient's information about sending the email to the P2P mail sending server in real time. To download the information you need on any computer The method of claim 1, The P2P mail sending peer sends mail messages downloaded from the P2P mail sending server to the mail message recipients by using the forwarding MTA and TCP MDA modules directly from the distributor's PC. To send emails distributed across multiple peers in a peer-to-peer fashion without the use of The method of claim 1, The P2P mail sending peer reports the mail message sending result to the P2P mail sending server. The email is sent directly from the distributor's PC, but the result is reported to the server and the P2P mail sending server is indirectly forwarded to each recipient. To see the results of email delivery