A pushlet im method for pushing a message from a first client device to a second client device includes the steps of: providing a java-based web service; receiving a message from the first client device, the message including information of a recipient entity; verifying identity of a sender entity who intends to send the message to the recipient entity using the first client device; and creating a thread according to the information of the recipient entity for pushing the message to the second client device that is associated with the recipient entity.
|
7. A computer system adapted to be operative over a communication network, configured to push at least one message from a first client device to a second client device, and comprising:
a processing unit; and
a memory, for storing a program code, wherein the program code instructs the processing unit to execute the following steps:
connecting to each of the first client device and the second client device, and receiving at least one message that is sent from the first client device via a java-based web service and that includes information of a recipient entity;
using the java-based web service to verify identity of a sender entity who intends to send the message to the recipient entity using the first client device; and
when the identity of the sender entity is verified, creating at least one thread according to the information of the recipient entity in the message for pushing the message to the second client device that is associated with the recipient entity.
1. A pushlet instant messaging (im) method for pushing at least one message from a first client device to at least one second client device, said pushlet im method to be implemented by a pushlet im framework including a pushlet im interface and a pushlet im server, the pushlet im server including a thread pool pattern, said pushlet im method comprising the steps of:
(A) providing, by the pushlet im interface, a java-based web service, each of the first client device and the second client device being capable of connecting to the pushlet im interface by executing a browser to access the java-based web service under a communication protocol of the java-based web service;
(B) receiving, by the pushlet im interface, the message that is sent from the first client device via the java-based web service and that includes information of a recipient entity;
(C) using, by the pushlet im interface, the java-based web service to verify identity of a sender entity who intends to send the message to the recipient entity using the first client device;
(D) sending, by the pushlet im interface, the message to the pushlet im server when the identity of the sender entity is verified in step (C); and
(E) creating, by the thread pool pattern, at least one thread according to the information of the recipient entity in the message for pushing the message to the second client device, which is associated with the recipient entity.
2. The pushlet im method as claimed in
determining, by the message-filtering module, whether the message includes the keyword; and
forwarding, by the message-filtering module, the message to the thread pool pattern when it is determined that the message does not include the keyword.
3. The pushlet im method as claimed in
the message received in step (B) further includes an identification code associated with the sender entity; and
in step (C), the pushlet im interface determines whether the identification code included in the message conforms with the identification code stored in the client database, and verifies the identity of the sender entity as the registered user entity when the determination is affirmative.
4. The pushlet im method as claimed in
wherein the information of the recipient entity is the identification code.
5. The pushlet im method as claimed in
wherein, in step (E), the thread pool pattern creates a plurality of threads for pushing simultaneously the message to each of the second client devices, the threads being dedicated to the second client devices, respectively.
6. The pushlet im method as claimed in
the threads being dedicated to the second client devices, respectively.
8. The computer system as claimed in
the program code further instructs the processing unit to determine whether the message includes the keyword, and forward the message when it is determined that the message does not include the keyword.
9. The computer system as claimed in
the message further includes an identification code associated with the sender entity; and
the program code further instructs the processing unit to determine whether the identification code included in the message conforms with the identification code stored in the client database, and verifies the identity of the sender entity as the registered user entity when the determination is affirmative.
10. The computer system as claimed in
wherein the information of the recipient entity is the identification code.
11. The computer system as claimed in
wherein the program code further instructs the processing unit to create a plurality of threads for pushing simultaneously the message to each of the second client devices, the threads being dedicated to the second client devices, respectively.
12. The computer system as claimed in
the threads being dedicated to the second client devices, respectively.
|
This application claims priority of Chinese Application Number 201410148922.7, filed on Apr. 14, 2014, the entire disclosure of which is incorporated herein by reference.
The present invention relates to a Pushlet instant messaging method and a Pushlet instant messaging framework.
It is found, from an experiment on a conventional Pushlet instant messaging (IM) server, that the speed at which client devices may receive messages becomes slower when a pushing period of the messages ranges between 300 ms to 1 s in the conventional Pushlet IM server. As a result, pending messages in an event queue that are to be pushed to the client devices may pile up since the conventional Pushlet IM server is configured to use a stack method for pushing messages one at a time, increasing load of the conventional Pushlet IM server and resulting in failure to instantly push messages to the client devices.
Moreover, the conventional Pushlet IM server communicates with the client devices based on hypertext transfer protocol (HTTP). Accordingly, the conventional Pushlet IM server cannot communicate with the client devices under other types of communication protocols, such as simple object access protocol (SOAP) and extensible markup language (XML). In other words, applicable fields of the conventional Pushlet IM server are limited.
Therefore, an object of the present invention is to provide a Pushlet instant messaging (IM) method capable of increasing throughput for transceiving messages, pushing the messages immediately, and communicating with any one of client devices based on various types of communication protocols.
Accordingly, a Pushlet IM method of the present invention is for pushing a message from a first client device to a second client device.
The Pushlet IM method is implemented by a Pushlet IM framework that includes a Pushlet IM interface and a Pushlet IM server. The Pushlet IM server includes a thread pool pattern.
The Pushlet IM method includes the following steps of:
(A) providing, by the Pushlet IM interface, a Java-based web service, each of the first client device and the second client device being capable of connecting to the Pushlet IM interface by executing a browser to access the Java-based web service under a communication protocol of the Java-based web service;
(B) receiving, by the Pushlet IM interface, at least one message that is sent from the first client device and that includes information of a recipient;
(C) verifying, by the Pushlet IM interface, identity of a sender entity who intends to send the message to the recipient using the first client device;
(D) sending, by the Pushlet IM interface, the message to the Pushlet IM server when the identity of the sender entity is verified in step (C); and
(E) creating, by the thread pool pattern, at least one thread according to the information of the recipient in the message for pushing the message to the second client device, which is associated with the recipient entity.
Another object of the present invention is to provide a Pushlet instant messaging (IM) framework capable of increasing throughput for transceiving messages, pushing the messages immediately, and communicating with any one of client devices based on various types of communication protocols.
According to another aspect, a Pushlet IM framework of the present invention is adapted to be operative over a communication network and is configured to push at least one message from a first client device to at least one second client device. The Pushlet IM framework includes a Pushlet IM interface and a Pushlet IM server.
The Pushlet IM interface is configured to provide a Java-based web service, and includes a sender entity-verifying module. The Pushlet IM server includes at least one thread pool pattern. The Pushlet IM interface connects to each of the first client device and the second client device, and receives the message that is sent from the first client device and that includes information of a recipient. The sender entity-verifying module of the Pushlet IM interface verifies identity of a sender entity who intends to send the message to the recipient using the first client device, and send the message to the Pushlet IM server when the identity of the sender entity is verified. The thread pool pattern creates at least one thread according to the information of the recipient in the message for pushing the message to the second client device that is associated with the recipient entity.
Other features and advantages of the present invention will become apparent in the following detailed description of the embodiment with reference to the accompanying drawings, of which:
Referring to
Since the web service 13 provided by the Pushlet IM interface 11 is based on Java programming language that is unconstrained for various platforms, the first and second client devices 2, 3 may not be restrained by a certain type of communication protocol, such as hypertext transfer protocol (HTTP), for accessing the Java-based web service 13 by executing a browser. In other words, as long as the first client device 2 and the second client device 3 comply with a communication protocol of the Java-based web service 13, the first and second client devices 2, 3 are capable of connecting to the Pushlet IM interface 11 to transceive the messages via the Pushlet IM server 12 under a data format complying with any type of communication protocol, such as HTTP, simple object access protocol (SOAP) and extensible markup language (XML).
Before sending and receiving the messages via the Pushlet IM framework 1, a sender entity and a recipient entity should be registered to the register module 15 of the Pushlet IM server 12 by providing register information (e.g., personal data) associated respectively with a sender and a recipient. After the sender entity and the recipient entity are successfully registered, the register module 15 issues identification (ID) codes that are dedicated to the sender and recipient entities, respectively. Meanwhile, the register module 15 stores the register information and the ID codes in a client database thereof such that the sender entity and the recipient entity are classified as registered users. Moreover, the register module 15 allows the identity verifying module 14 of the Pushlet IM interface 11 to access the client database for ID verification of the sender entity and the recipient entity. It is noted that the sender entity and the recipient entity in this embodiment refer respectively to the sender and the recipient who intend to use respectively the first client device 2 and the second client device 3 to access the Java-base web service 13 for transceiving at least one message, but may refer to the first client device 2 and the second client device 3 in other embodiments. In the case where the sender entity and the recipient entity refer to the first client device 2 and the second client device 3, the register information may include hardware information of the first and second client devices 2, 3, and the ID codes are dedicated to the first and second client devices 2, 3, respectively.
In step S11 of the Pushlet IM method, the first client device 2 connects to the Pushlet IM interface 11 by executing a browser to access the Java-based web service 13 under the communication protocol of the Java-based web service 13. Then, in step S12, the Java-based web service 13 provided by the Pushlet IM interface 11 receives the message that is sent from the first client device 2 and that is based on any one of the well-defined data formats. The message includes a main content, the ID code of the sender entity and information of the recipient entity. For example, the information of the recipient entity is the ID code dedicated to the recipient entity.
After receiving the message from the first client device 2, the Java-based web service 13 sends the message to the identity verifying module 14 in step S13. In step S14, the identity verifying module 14 verifies identity of the sender entity who intends to send the message to the recipient entity using the first client device 2. For instance, the identity verifying module 14 determines whether the ID code included in the message conforms with the ID code stored in the client database of the register module 15, and verifies the identity of the sender entity is the registered user when the determination is affirmative. If the identity of the sender entity is verified as the registered user, the message will be sent to the Pushlet IM server 12 in step S15. Otherwise, in step S16, sending of the message is deemed to have failed and the first client device 2 will be notified accordingly.
After the Pushlet IM server 12 receives the message, the message-filtering module 16 of the Pushlet IM server 12 filters the message in step S17. For example, the message-filtering module 16 pre-stores at least one keyword, determines whether the message includes the keyword, and forwards the message to the thread pool pattern 17 when it is determined that the message does not include the keyword. It is understood that the keyword may vary based upon different requests such that transmission of unwanted messages may be prevented. When it is determined that the message includes the keyword, sending of the message is deemed to have failed and the first client device 2 will be notified accordingly in step S18.
In step S19, the thread pool pattern 17, according to the information of the recipient entity in the message, creates at least one thread that is dedicated to the recipient entity (e.g., the recipient or the second client device 3). Then, in step S20, the thread pool pattern 17 sends the message to a browser of the second client device 3 that is associated with the recipient entity through the thread.
For example, see
In a case that the Pushlet IM server 12 receives in sequence a plurality of messages including information of a plurality of recipient entities that are associated respectively with a plurality of second client devices, the thread pool pattern 17 may create, in step S19, a plurality of threads for pushing simultaneously the messages to the second client devices, respectively. The threads are dedicated to the second client devices, respectively.
Moreover, the Pushlet IM server 12 further includes a message-managing module 18 for managing sent messages. The message-managing module 18 may provide additional functions using the sent messages, such as generating information report and user-log record, providing the keyword for filtering the message to the message-filtering module 16, etc.
To conclude, by virtue of the Java-based web service 13 of the Pushlet IM interface 11, the first and second client devices 2, 3 are capable of connecting to the Pushlet IM interface 11 and are operable to push the messages via the Pushlet IM server 12 with any data format of various types of communication protocols. Moreover, the thread pool pattern 17 of the Pushlet IM server 12 creates, according to the information of the recipient entities in the message, the threads that are dedicated respectively to the registered users such that messages may be sent instantly and simultaneously to the recipient entities.
While the present invention has been described in connection with what is considered the most practical embodiment, it is understood that this invention is not limited to the disclosed embodiment but is intended to cover various arrangements included within the spirit and scope of the broadest interpretation so as to encompass all such modifications and equivalent arrangements.
Xu, Cheng, Guan, Peng, Huo, Tong-Wang, Wan, Jin-Guang
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
7299409, | Mar 07 2003 | International Business Machines Corporation | Dynamically updating rendered content |
20030033533, | |||
20060031234, | |||
20060117318, | |||
20090210501, | |||
20140229558, | |||
CN101330473, | |||
CN103347006, | |||
CN103365718, | |||
EP2397950, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Jan 02 2015 | GUAN, PENG | Wistron Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034891 | /0039 | |
Jan 02 2015 | XU, CHENG | Wistron Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034891 | /0039 | |
Jan 02 2015 | HUO, TONG-WANG | Wistron Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034891 | /0039 | |
Jan 02 2015 | WAN, JIN-GUANG | Wistron Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034891 | /0039 | |
Feb 04 2015 | Wistron Corporation | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Jan 11 2023 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Date | Maintenance Schedule |
Oct 15 2022 | 4 years fee payment window open |
Apr 15 2023 | 6 months grace period start (w surcharge) |
Oct 15 2023 | patent expiry (for year 4) |
Oct 15 2025 | 2 years to revive unintentionally abandoned end. (for year 4) |
Oct 15 2026 | 8 years fee payment window open |
Apr 15 2027 | 6 months grace period start (w surcharge) |
Oct 15 2027 | patent expiry (for year 8) |
Oct 15 2029 | 2 years to revive unintentionally abandoned end. (for year 8) |
Oct 15 2030 | 12 years fee payment window open |
Apr 15 2031 | 6 months grace period start (w surcharge) |
Oct 15 2031 | patent expiry (for year 12) |
Oct 15 2033 | 2 years to revive unintentionally abandoned end. (for year 12) |