冰3.4.2详细文档：从入门到HelloWorld示例

需积分: 15 152 浏览量更新于2024-07-26 收藏 4.8MB PDF 举报

"冰（Ice）是ZeroC公司开发的一种高性能、分布式、跨语言的RPC框架，主要用于构建分布式应用程序和服务间的通信。这份文档是Ice 3.4.2版本的官方参考手册，为学习和使用Ice提供了详尽的指导。首先，章节1.1概述了Ice的基本架构。术语部分介绍了核心概念，如Terminology（术语），包括服务（Service）、适配器（Adapter）、序列化（Serialization）、以及Slice，后者是一种专门为Ice设计的声明性语言，用于描述服务接口和操作。语言映射（Language Mappings）则展示了如何在不同编程语言中实现 Ice 应用程序，例如C++、Java、C#、Visual Basic、Objective-C、Python、Ruby和PHP等。在HelloWorld Application部分，从编写Slice定义开始，引导读者如何使用这些语言来创建一个简单的冰应用。通过实例展示如何通过各种语言环境配置和实现客户端和服务器结构，以及冰协议的工作原理。接着，第1.3节深入探讨了Slice语言。这部分包括编译流程（Slice Compilation）、源文件组织（Source Files）、词法规则（Lexical Rules）、模块系统（Modules）、基本类型（如数值、字符串等）、用户自定义类型（如枚举、结构体、序列、字典）、常量和字面量等语法细节。整体而言，这份文档不仅提供了Ice的基础知识，还为开发者提供了丰富的实战指南，无论是初次接触Ice的新手，还是希望深入了解其内部机制的高级用户，都能从中获益匪浅。通过阅读和实践这份文档，读者可以掌握如何利用Ice构建高效、可靠和跨平台的分布式系统。"

Ice 3.4.2 Documentation

Any object of the object adapter can be accessed using such a proxy, regardless of whether that object is also a well-known object.

Notice that an indirect proxy contains no addressing information. To determine the correct server, the client-side run time passes the proxy

information to a . In turn, the location service uses the object identity or the object adapter identifier as the key in a lookuplocation service

table that contains the address of the server and returns the current server address to the client. The client-side run time now knows how to

contact the server and dispatches the client request as usual.

The entire process is similar to the mapping from Internet domain names to IP address by the Domain Name Service (DNS): when we use a

domain name, such as , to look up a web page, the host name is first resolved to an IP address behind the scenes and,www.zeroc.com

once the correct IP address is known, the IP address is used to connect to the server. With Ice, the mapping is from an object identity or

object adapter identifier to a protocol-address pair, but otherwise very similar. The client-side run time knows how to contact the location

service via configuration (just as web browsers know which DNS server to use via configuration).

Direct Versus Indirect Binding

The process of resolving the information in a proxy to protocol-address pair is known as . Not surprisingly, is used forbinding direct binding

direct proxies, and is used for indirect proxies.indirect binding

The main advantage of indirect binding is that it allows us to move servers around (that is, change their address) without invalidating existing

proxies that are held by clients. In other words, direct proxies avoid the extra lookup to locate the server but no longer work if a server is

moved to a different machine. On the other hand, indirect proxies continue to work even if we move (or ) a server.migrate

Fixed Proxies

A is a proxy that is bound to a particular connection: instead of containing addressing information or an adapter name, the proxyfixed proxy

contains a connection handle. The connection handle stays valid only for as long as the connection stays open so, once the connection is

closed, the proxy no longer works (and will never work again). Fixed proxies cannot be marshaled, that is, they cannot be passed as

parameters on operation invocations. Fixed proxies are used to allow , so a server can make callbacks to a clientbidirectional communication

without having to open a new connection.

Routed Proxies

A is a proxy that forwards all invocations to a specific target object, instead of sending invocations directly to the actual target.routed proxy

Routed proxies are useful for implementing services such as , which enables clients to communicate with servers that are behind aGlacier2

firewall.

Replication

In Ice, involves making object adapters (and their objects) available at multiple addresses. The goal of replication is usually toreplication

provide redundancy by running the same server on several computers. If one of the computers should happen to fail, a server still remains

available on the others.

The use of replication implies that applications are designed for it. In particular, it means a client can access an object via one address and

obtain the same result as from any other address. Either these objects are stateless, or their implementations are designed to synchronize

with a database (or each other) in order to maintain a consistent view of each object's state.

Ice supports a limited form of replication when a proxy specifies multiple addresses for an object. The Ice run time selects one of the

addresses at random for its and tries all of them in the case of a failure. For example, consider this proxy:initial connection attempt

SimplePrinter:tcp -h server1 -p 10001:tcp -h server2 -p 10002

The proxy states that the object with identity is available using TCP at two addresses, one on the host andSimplePrinter server1

another on the host . The burden falls to users or system administrators to ensure that the servers are actually running on theseserver2

computers at the specified ports.

Replica Groups

In addition to the proxy-based replication described above, Ice supports a more useful form of replication known as thatreplica groups

requires the use of a .location service

A replica group has a unique identifier and consists of any number of object adapters. An object adapter may be a member of at most one

replica group; such an adapter is considered to be a .replicated object adapter

After a replica group has been established, its identifier can be used in an indirect proxy in place of an adapter identifier. For example, a

replica group identified as can be used in a proxy as shown below:PrinterAdapters

Ice 3.4.2 Documentation

SimplePrinter@PrinterAdapters

The replica group is treated by the location service as a "virtual object adapter." The behavior of the location service when resolving an

indirect proxy containing a replica group id is an implementation detail. For example, the location service could decide to return the

addresses of all object adapters in the group, in which case the client's Ice run time would select one of the addresses at random using the

limited form of replication discussed earlier. Another possibility is for the location service to return only one address, which it decided upon

using some heuristic.

Regardless of the way in which a location service resolves a replica group, the key benefit is indirection: the location service as a middleman

can add more intelligence to the binding process.

Servants

As we mentioned, an is a conceptual entity that has a type, identity, and addressing information. However, client requestsIce Object

ultimately must end up with a concrete server-side processing entity that can provide the behavior for an operation invocation. To put this

differently, a client request must ultimately end up executing code inside the server, with that code written in a specific programming

language and executing on a specific processor.

The server-side artifact that provides behavior for operation invocations is known as a . A servant provides substance for (or servant

) one or more Ice objects. In practice, a servant is simply an instance of a class that is written by the server developer and that isincarnates

registered with the server-side run time as the servant for one or more Ice objects. Methods on the class correspond to the operations on the

Ice object's interface and provide the behavior for the operations.

A single servant can incarnate a single Ice object at a time or several Ice objects simultaneously. If the former, the identity of the Ice object

incarnated by the servant is implicit in the servant. If the latter, the servant is provided the identity of the Ice object with each request, so it

can decide which object to incarnate for the duration of the request.

Conversely, a single Ice object can have multiple servants. For example, we might choose to create a proxy for an Ice object with two

different addresses for different machines. In that case, we will have two servers, with each server containing a servant for the same Ice

object. When a client invokes an operation on such an Ice object, the client-side run time sends the request to exactly one server. In other

words, multiple servants for a single Ice object allow you to build redundant systems: the client-side run time attempts to send the request to

one server and, if that attempt fails, sends the request to the second server. An error is reported back to the client-side application code only

if that second attempt also fails.

At-Most-Once Semantics

Ice requests have semantics: the Ice run time does its best to deliver a request to the correct destination and, depending onat-most-once

the exact circumstances, may retry a failed request. Ice guarantees that it will either deliver the request, or, if it cannot deliver the request,

inform the client with an appropriate exception; under no circumstances is a request delivered twice, that is, retries are attempted only if it is

known that a previous attempt definitely failed.

One exception to this rule are datagram invocations over UDP transports. For these, duplicated UDP packets can lead to a

violation of at-most-once semantics.

At-most-once semantics are important because they guarantee that operations that are not can be used safely. An idempotentidempotent

operation is an operation that, if executed twice, has the same effect as if executed once. For example, is an idempotent operation:x = 1;

if we execute the operation twice, the end result is the same as if we had executed it once. On the other hand, is not idempotent: if wex++;

execute the operation twice, the end result is not the same as if we had executed it once.

Without at-most-once semantics, we can build distributed systems that are more robust in the presence of network failures. However,

realistic systems require non-idempotent operations, so at-most-once semantics are a necessity, even though they make the system less

robust in the presence of network failures. Ice permits you to mark individual operations as idempotent. For such operations, the Ice run time

uses a more aggressive error recovery mechanism than for non-idempotent operations.

Synchronous Method Invocation

By default, the request dispatch model used by Ice is a synchronous remote procedure call: an operation invocation behaves like a local

procedure call, that is, the client thread is suspended for the duration of the call and resumes when the call completes (and all its results are

available).

Asynchronous Method Invocation

Ice also supports : clients can invoke operations , that is, the client uses a proxy asasynchronous method invocation (AMI) asynchronously

Ice 3.4.2 Documentation

usual to invoke an operation but, in addition to passing the normal parameters, also passes a and the client invocationcallback object

returns immediately. Once the operation completes, the client-side run time invokes a method on the callback object passed initially, passing

the results of the operation to the callback object (or, in case of failure, passing exception information).

The server cannot distinguish an asynchronous invocation from a synchronous one — either way, the server simply sees that a client has

invoked an operation on an object.

Asynchronous Method Dispatch

Asynchronous method dispatch (AMD) is the server-side equivalent of AMI. For synchronous dispatch (the default), the server-side run time

up-calls into the application code in the server in response to an operation invocation. While the operation is executing (or sleeping, for

example, because it is waiting for data), a thread of execution is tied up in the server; that thread is released only when the operation

completes.

With asynchronous method dispatch, the server-side application code is informed of the arrival of an operation invocation. However, instead

of being forced to process the request immediately, the server-side application can choose to delay processing of the request and, in doing

so, releases the execution thread for the request. The server-side application code is now free to do whatever it likes. Eventually, once the

results of the operation are available, the server-side application code makes an API call to inform the server-side Ice run time that a request

that was dispatched previously is now complete; at that point, the results of the operation are returned to the client.

Asynchronous method dispatch is useful if, for example, a server offers operations that block clients for an extended period of time. For

example, the server may have an object with a operation that returns data from an external, asynchronous data source and that blocksget

clients until the data becomes available. With synchronous dispatch, each client waiting for data to arrive ties up an execution thread in the

server. Clearly, this approach does not scale beyond a few dozen clients. With asynchronous dispatch, hundreds or thousands of clients can

be blocked in the same operation invocation without tying up any threads in the server.

Another way to use asynchronous method dispatch is to complete an operation, so the results of the operation are returned to the client, but

to keep the execution thread of the operation beyond the duration of the operation invocation. This allows you to continue processing after

results have been returned to the client, for example, to perform cleanup or write updates to persistent storage.

Synchronous and asynchronous method dispatch are transparent to the client, that is, the client cannot tell whether a server chose to

process a request synchronously or asynchronously.

Oneway Method Invocation

Clients can invoke an operation as a operation. A oneway invocation has "best effort" semantics. For a oneway invocation, theoneway

client-side run time hands the invocation to the local transport, and the invocation completes on the client side as soon as the local transport

has buffered the invocation. The actual invocation is then sent asynchronously by the operating system. The server does not reply to oneway

invocations, that is, traffic flows only from client to server, but not vice versa.

Oneway invocations are unreliable. For example, the target object may not exist, in which case the invocation is simply lost. Similarly, the

operation may be dispatched to a servant in the server, but the operation may fail (for example, because parameter values are invalid); if so,

the client receives no notification that something has gone wrong.

Oneway invocations are possible only on that do not have a return value, do not have out-parameters, and do not throw useroperations

exceptions.

To the application code on the server-side, oneway invocations are transparent, that is, there is no way to distinguish a twoway invocation

from a oneway invocation.

Oneway invocations are available only if the target object offers a stream-oriented transport, such as TCP/IP or SSL.

Note that, even though oneway operations are sent over a stream-oriented transport, they may be processed out of order in the server. This

can happen because each invocation may be dispatched in its own thread: even though the invocations are in the order in which theinitiated

invocations arrive at the server, this does not mean that they will be in that order — the vagaries of thread scheduling can result inprocessed

a oneway invocation completing before other oneway invocations that were received earlier.

Batched Oneway Method Invocation

Each oneway invocation sends a separate message to the server. For a series of short messages, the overhead of doing so is considerable:

the client- and server-side run time each must switch between user mode and kernel mode for each message and, at the networking level,

each message incurs the overheads of flow-control and acknowledgement.

Batched oneway invocations allow you to send a series of oneway invocations as a single message: every time you invoke a batched

oneway operation, the invocation is buffered in the client-side run time. Once you have accumulated all the oneway invocations you want to

send, you make a separate API call to send all the invocations at once. The client-side run time then sends all of the buffered invocations in

a single message, and the server receives all of the invocations in a single message. This avoids the overhead of repeatedly trapping into

the kernel for both client and server, and is much easier on the network between them because one large message can be transmitted more

efficiently than many small ones.

Ice 3.4.2 Documentation

The individual invocations in a batched oneway message are dispatched by a single thread in the order in which they were placed into the

batch. This guarantees that the individual operations in a batched oneway message are processed in order in the server.

Batched oneway invocations are particularly useful for messaging services, such as , and for fine-grained interfaces that offer IceStorm set

operations for small attributes.

Datagram Invocations

Datagram invocations have "best effort" semantics similar to oneway invocations. However, datagram invocations require the object to offer

UDP as a transport (whereas oneway invocations require TCP/IP).

Like a oneway invocation, a datagram invocation can be made only if the operation does not have a return value, out-parameters, or user

exceptions. A datagram invocation uses UDP to invoke the operation. The operation returns as soon as the local UDP stack has accepted

the message; the actual operation invocation is sent asynchronously by the network stack behind the scenes.

Datagrams, like oneway invocations, are unreliable: the target object may not exist in the server, the server may not be running, or the

operation may be invoked in the server but fail due to invalid parameters sent by the client. As for oneway invocations, the client receives no

notification of such errors.

However, unlike oneway invocations, datagram invocations have a number of additional error scenarios:

Individual invocations may simply be lost in the network.

This is due to the unreliable delivery of UDP packets. For example, if you invoke three operations in sequence, the middle invocation

may be lost. (The same thing cannot happen for oneway invocations — because they are delivered over a connection-oriented

transport, individual invocations cannot be lost.)

Individual invocations may arrive out of order.

Again, this is due to the nature of UDP datagrams. Because each invocation is sent as a separate datagram, and individual

datagrams can take different paths through the network, it can happen that invocations arrive in an order that differs from the order

in which they were sent.

Datagram invocations are well suited for small messages on LANs, where the likelihood of loss is small. They are also suited to situations in

which low latency is more important than reliability, such as for fast, interactive internet applications. Finally, datagram invocations can be

used to multicast messages to multiple servers simultaneously.

Batched Datagram Invocations

As for batched oneway invocations, allow you to accumulate a number of invocations in a buffer and thenbatched datagram invocations

send the entire buffer as a single datagram by making an API call to flush the buffer. Batched datagrams reduce the overhead of repeated

system calls and allow the underlying network to operate more efficiently. However, batched datagram invocations are useful only for

batched messages whose total size does not substantially exceed the PDU limit of the network: if the size of a batched datagram gets too

large, UDP fragmentation makes it more likely that one or more fragments are lost, which results in the loss of the entire batched message.

However, you are guaranteed that either all invocations in a batch will be delivered, or none will be delivered. It is impossible for individual

invocations within a batch to be lost.

Batched datagrams use a single thread in the server to dispatch the individual invocations in a batch. This guarantees that the invocations

are made in the order in which they were queued — invocations cannot appear to be reordered in the server.

Run-Time Exceptions

Any operation invocation can raise a . Run-time exceptions are pre-defined by the Ice run time and cover common errorrun-time exception

conditions, such as connection failure, connection timeout, or resource allocation failure. Run-time exceptions are presented to the

application as native exceptions and so integrate neatly with the native exception handling capabilities of languages that support exception

handling.

User Exceptions

A server indicates application-specific error conditions by raising to clients. User exceptions can carry an arbitrary amount ofuser exceptions

complex data and can be arranged into inheritance hierarchies, which makes it easy for clients to handle categories of errors generically, by

catching an exception that is further up the inheritance hierarchy. Like run-time exceptions, user exceptions map to native exceptions.

Properties

Much of the Ice run time is configurable via . Properties are name-value pairs, such as .properties Ice.Default.Protocol=tcp

Properties are typically stored in text files and parsed by the Ice run time to configure various options, such as the thread pool size, the level

of tracing, and various other configuration parameters.

剩余1766页未读，继续阅读

刹那的时光

粉丝: 3
资源: 3

冰3.4.2详细文档：从入门到HelloWorld示例

ice3.4文档

ICE开发文档 Ice-3.4.0.pdf

ice教程和ice中文版手册

ice分布式程序设计pdf

ice 中间件.pdf

centos编译ice3.6.4

Flink+iceberg环境搭建

ice_load_init(): failed to open file: /lib/firmware/intel/ice/dip/ice.pkg

fensap-ice使用教程

ICE2PCS02G控制器在实现CCM-PFC时有哪些关键特性和工作原理？请结合技术文档进行详细说明。

最新资源