I have written some socket programs, with the gradual complexity of the program, directly with the socket programming seems to have some trouble. According to the idea that the software should be modularized, the socket communication part of the software should be made into a "middleware" in relative independence. I used C + + wrote a simple "remote Call middleware" principle demo program, shared out and everyone discussed (my level is limited, if there are errors, welcome criticism). This program demonstrates a simple set of remote object invocations that the application accesses to C + + objects on the remote computer through the local proxy object, as conveniently as accessing the real local object. The principle of this remote object calling program is not difficult, the service side has a communication class processing socket communication, provides the service end object of various service to pass own pointer to the object of the correspondence class, save in a std::map, the object of the communication class invokes the C + + object of different functions of the service side according to the request of the client, The call result is then returned to the client. The client also has a communication class to handle socket communication, the client's proxy object on behalf of the server object to accept the call, and then through the communication class to identify the class, function identification, function parameters to the server, call the server-side object, and then return the call result to the caller of the client. Attachment is the source of the program, the real I original.
|
| File: |
Gmrcmw0324.tar |
| Size: |
100KB |
| Download: |
Download |
|
It's just a simple demo, and I can't guarantee it's not wrong. You can use the source code in this program in your own program, as long as you are responsible for the quality of the program, and indicate the reference part of the original author.
This program is the "C + + simple Remote Call middleware design (a)" version of the upgrade, this time to achieve according to the client's request dynamic creation and revocation of service-side objects. The original "C + + simple Remote Call middleware design (a)" program in a service-side class has only one instance, this service-side object is called by different instances of the same proxy class on the client, and the service function of the server-side object must be reentrant so that the server-side object cannot save the intermediate information in multiple invocations. The current "C + + simple remote invocation middleware design (ii)" program can dynamically create a corresponding service-side class instance for each client proxy class instance, so that the intermediate information can be saved. This feature is used in my program to implement a file read-only access class.
Client Fileagent class:
Class Fileagent:p ublic seragent, Filecsargbase
{
Protected
Guint32 Pos_file;
BOOL End_file;
Guint32 Size_file;
Guint32 Size_read;
Public
Gint32 Init (communicatecli *ap_client);
Gint32 Open (char* filename);
Gint32 Read (char *ap_buf, Guint32 a_size_read);
Gint32 Seek (Guint32 a_pos);
Gint32 Close ();
Gint32 Erase ();
BOOL Get_if_end () {return end_file;}
Guint32 Get_size_read () {return size_read;}
}; |
Service-Side Fileser class:
| Class Fileser:p ublic moduleserver, Filecsargbase
{
Protected
Std::string Name_module;
static Guint32 counter;
Idobj M_id_obj;
Communicateser *p_my_comm;
Glib::mutex Mutex_clone;
Std::ifstream My_file;
Protected
typedef void (Fileser::* p_func) (Char *ap_recv, char *ap_send);
P_func P_func;
Std::map<guint32, p_func> Map_func;
Std::map<guint32, P_func>::iterator It_map_func;
typedef std::p air<guint32, p_func> ps_func;
Public
void Call_switch (char *ap_recv, char *ap_send);
void Init (Communicateser *ap_my_comm, idobj a_id_obj);
Protected
void Init ();
void Clone (char *ap_recv, char *ap_send);
void Open (char *ap_recv, char *ap_send);
void Read (char *ap_recv, char *ap_send);
void Seek (char *ap_recv, char *ap_send);
void Close (char *ap_recv, char *ap_send);
void Erase (char *ap_recv, char *ap_send);
}; |
When an instance of the client proxy class initializes, it invokes the server-side object's Clone method, the Clone method creates a new instance of the service-side object, saves the new instance's pointer in a std::map, and uses the new instance's object identifier to do the key in the Std::map. This object identifier is returned to the client, and then the client can use this object identifier to invoke the server object, when the server-side object and the client proxy are one-to-one services, so the server-side object can save the open file object, the file reads the pointer, and other intermediate information. When a client agent no longer needs a service it invokes the erase method of the server-side object, the erase method clears the server-side object's information in Std::map, and then clears the object from memory. I demonstrated the remote file read and move read pointer in this program. If the server-side object does not need to store intermediate information, then as long as there is one instance, the client's proxy invokes it with the same identity. I demonstrated this in a demo program, calling a remote object to add and subtract integers.
I am in my WIN2K/MINGW environment to compile test this program, the program needs to use the GTKMM library, in this program I do not deal with the network byte order problem, practical procedures should deal with this problem.
MinGW The Compile command is:
Server-side program: g++-o gmrcmwser gmrcmwser.cc ' pkg-config.exe gtkmm-2.4--cflags--libs '-lgthread-2.0-lws2_32
Client program: g++-o gmrcmwcli gmrcmwcli.cc ' pkg-config.exe gtkmm-2.4--cflags--libs '-lgthread-2.0-lws2_32
This program source code can be ported to Linux, Linux under the compiler command is:
Server-side program: g++-o gmrcmwser gmrcmwser.cc ' pkg-config gtkmm-2.4--cflags--libs '-lgthread-2.0
Client program: g++-o gmrcmwcli gmrcmwcli.cc ' pkg-config gtkmm-2.4--cflags--libs '-lgthread-2.0
Zhujiang
March 24, 2007
Http://blog.chinaunix.net/u/21585/showart_264034.html
