1Event::RPC(3) User Contributed Perl Documentation Event::RPC(3)
2
3
4
6 Event::RPC - Event based transparent Client/Server RPC framework
7
9 #-- Server Code
10 use Event::RPC::Server;
11 use My::TestModule;
12 my $server = Event::RPC::Server->new (
13 port => 5555,
14 classes => { "My::TestModule" => { ... } },
15 );
16 $server->start;
17
18 ----------------------------------------------------------
19
20 #-- Client Code
21 use Event::RPC::Client;
22 my $client = Event::RPC::Client->new (
23 server => "localhost",
24 port => 5555,
25 );
26 $client->connect;
27
28 #-- Call methods of My::TestModule on the server
29 my $obj = My::TestModule->new ( foo => "bar" );
30 my $foo = $obj->get_foo;
31
33 Event::RPC supports you in developing Event based networking
34 client/server applications with transparent object/method access from
35 the client to the server. Network communication is optionally encrypted
36 using IO::Socket::SSL. Several event loop managers are supported due to
37 an extensible API. Currently Event and Glib are implemented.
38
40 Event::RPC consists of a server and a client library. The server
41 exports a list of classes and methods, which are allowed to be called
42 over the network. More specific it acts as a proxy for objects created
43 on the server side (on demand of the connected clients) which handles
44 client side methods calls with transport of method arguments and return
45 values.
46
47 The object proxy handles refcounting and destruction of objects created
48 by clients properly. Objects as method parameters and return values are
49 handled as well (although with some limitations, see below).
50
51 For the client the whole thing is totally transparent - once connected
52 to the server it doesn't know whether it calls methods on local or
53 remote objects.
54
55 Also the methods on the server newer know whether they are called
56 locally or from a connected client. Your application logic is not
57 affected by Event::RPC at all, at least if it has a rudimentary clean
58 OO design.
59
60 For details on implementing servers and clients please refer to the man
61 pages of Event::RPC::Server and Event::RPC::Client.
62
64 Event::RPC needs either one of the following modules on the server
65 (they're not necessary on the client):
66
67 Event
68 Glib
69
70 They're needed for event handling resp. mainloop implementation. If
71 you like to use SSL encryption you need to install
72
73 IO::Socket::SSL
74
75 As well Event::RPC makes heavy use of the
76
77 Storable
78
79 module, which is part of the Perl standard library. It's important that
80 both client and server use exactly the same version of the Storable
81 module! Otherwise Event::RPC client/server communication will fail
82 badly.
83
85 You get the latest installation tarballs and online documentation at
86 this location:
87
88 http://www.exit1.org/Event-RPC/
89
90 If your system meets the requirements mentioned above, installation is
91 just:
92
93 perl Makefile.PL
94 make test
95 make install
96
98 The tarball includes an examples/ directory which contains two
99 programs:
100
101 server.pl
102 client.pl
103
104 Just execute them with --help to get the usage. They do some very
105 simple communication but are good to test your setup, in particular in
106 a mixed environment.
107
109 Although the classes and objects on the server are accessed
110 transparently by the client there are some limitations should be aware
111 of. With a clean object oriented design these should be no problem in
112 real applications:
113
114 Direct object data manipulation is forbidden
115 All objects reside on the server and they keep there! The client just
116 has specially wrapped proxy objects, which trigger the necessary magic
117 to access the object's methods on the server. Complete objects are
118 never transferred from the server to the client, so something like this
119 does not work:
120
121 $object->{data} = "changed data";
122
123 (assuming $object is a hash ref on the server).
124
125 Only method calls are transferred to the server, so even for "simple"
126 data manipulation a method call is necessary:
127
128 $object->set_data ("changed data");
129
130 As well for reading an object attribute. Accessing a hash key will
131 fail:
132
133 my $data = $object->{data};
134
135 Instead call a method which returns the 'data' member:
136
137 my $data = $object->get_data;
138
139 Methods may exchange objects, but not in a too complex structure
140 Event::RPC handles methods which return objects. The only requirement
141 is that they are declared as a Object returner on the server (refer to
142 Event::RPC::Server for details), but not if the object is hided inside
143 a deep complex data structure.
144
145 An array or hash ref of objects is Ok, but not more. This would require
146 to much expensive runtime data inspection.
147
148 Object receiving parameters are more restrictive, since even hiding
149 them inside one array or hash ref is not allowed. They must be passed
150 as a direkt argument of the method subroutine.
151
153 JA~Xrn Reder <joern at zyn dot de>
154
156 Copyright (C) 2002-2006 by Joern Reder, All Rights Reserved.
157
158 This library is free software; you can redistribute it and/or modify it
159 under the same terms as Perl itself.
160
161
162
163perl v5.12.0 2008-10-25 Event::RPC(3)