发信人: crazyjava()
整理人: (2000-02-17 19:22:28), 站内信件
|
SOCKETS
While flexible, using sockets to communicate between client
and server can be cumbersome because of all the details you
have to handle by yourself.
To create a simple client-side connection using sockets, you
must do the following:
1) Locate the remote server and open a socket connection to it.
2) Marshal the parameters to be transmitted, including a value
that identifies the service you're requesting.
3) Transmit the parameters.
4) Listen for, and receive, the response from the server.
5) Decode the response from the server, unmarshaling its
components if necessary.
The most complex part of all this is sending and receiving
parameters. If the parameters you're sending to the server,
and the value it returns, are primitive (that is, non-object)
values, the process is fairly straightforward. If, however,
you want to send an object as a parameter, or receive one
as a return value, things get more exciting. To send objects
via a socket connection, you must first extract each of the
object's attributes, then marshal and transmit them. Of course,
if any attribute of your object is itself an object, you must
apply this technique recursively --- only primitive values
can be sent across the socket stream.
Implementing the server-side of this connection is no easier
than implementing a client. The server object must unmarshal
any parameters it receives, decode the value telling it what
service to perform, and so on.
All of this marshaling and unmarshaling might lead you to wish
that Java included an RPC facility, which would at least help
you pack and unpack your arguments. Rather than just RPC,
however, Java provides that RMI facility, which goes RPC one
better. For right now you might wonder why you might choose
to use sockets to communicate with remote objects when RMI
is available? Here are two possible reasons:
1) To commnicate with non-Java objects and programs: Not all
software on networks is written in Java --- at least,
not yet. Until it is, form time to time you will need
to interface a Java program with a non-Java program.
Sockets are a good way to do this, because data transmitted
over a socket is reduced to its lowest common denominator:
a stream of bytes. A program written in almost any language,
running on almost any platform, can deal with a stream
of bytes.
2) To communicate as efficiently as possible: The convenience
of RPC, RMI, and other facilities extracts a price in the
form of processing overhead. A well-designed socket
interface between programs can outperform on based on such
higher-level facilities. If your server must handle large
volumes of requests, this may be important to you.
As usual, deciding whether to use socket, RMI, CORBA, or some
other facility involves a design tradeoff. A program written
using sockets is larger and more complex than one written
using RMI, yet may perform better. This choice is analogous
to the choice of programming languages: a program written in
assembly language can, in principle, outpreform one written
in C or Java. But an assembly program is much harder to write,
is likely to contain more errors, and is more difficult to
maintain than a program written in a high-level language.
/Crazyjava
--
孤身走我路...
其实，路，两个人一起走比一个人要好。
email: [email protected]
※ 修改:．crazyjava 于 Jul 30 17:06:35 修改本文．[FROM: 139.87.93.173]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 139.87.93.173]
|
|