WindRiver TIPC程序员指南：高效进程间通信

需积分: 9 34 浏览量更新于2024-07-19 收藏 1.6MB PDF 举报

"tipc_programmers_guide - 透明进程间通信(TIPC)网络协议使得TIPC网络中的应用程序能够快速高效地互相通信。该资源主要针对WindRiver TIPC，这是一个在VxWorks操作系统环境下使用的通信协议。" 透明进程间通信(TIPC)是一种专为集群计算环境设计的网络协议，它允许在相同或不同计算机上的进程之间进行直接、高效的通信。TIPC的核心目标是提供一种透明的方式，使应用能够在不关心彼此位置的情况下相互通信，从而降低了网络编程的复杂性。 WindRiver TIPC是WindRiver Systems公司开发的一个实现，特别针对其嵌入式实时操作系统VxWorks。VxWorks是一个广泛应用于航空、航天、医疗设备、工业自动化等领域的实时操作系统。TIPC的集成使得VxWorks系统在高可用性和高性能通信方面具有优势，尤其适合那些对延迟敏感和需要高可靠性的应用场景。在《WindRiver TIPC Programmer's Guide》中，开发者可以找到关于如何在VxWorks环境下使用TIPC的详细指南。该文档可能涵盖了以下内容： 1. **TIPC概念**：介绍TIPC的基本原理，包括地址空间、消息传递机制、服务发现和故障恢复策略。 2. **API和编程接口**：详细说明TIPC提供的API，包括创建、发送、接收消息的函数，以及如何注册和查找服务。 3. **配置与设置**：解释如何在VxWorks系统中配置TIPC，包括网络参数、端口映射和故障切换策略。 4. **性能优化**：提供关于如何最大化TIPC性能的建议，包括消息大小、传输策略和负载平衡。 5. **服务发现与动态组播**：TIPC支持动态服务发现，使得应用能够自动发现并连接到其他提供特定服务的节点。 6. **错误处理和调试**：介绍如何诊断和解决TIPC相关的问题，以及可用的调试工具和日志功能。 7. **兼容性和集成**：讨论与其他通信协议（如TCP/IP）的交互，以及如何在现有系统中集成TIPC。 8. **案例研究和最佳实践**：可能包含实际项目中的应用示例和成功部署TIPC的经验分享。该指南对于任何希望在VxWorks上构建分布式、高效率、容错性强的应用程序的开发者来说，都是一份宝贵的参考资料。通过深入理解和熟练运用TIPC，开发者能够充分利用VxWorks的网络能力，构建出更加健壮和高性能的系统。

Wind River TIPC

Programmer's Guide, 1.7.6

separate native API (see 7. TIPC Native API) is available for TIPC programming.

Some ports are also created and used by Wind River TIPC, itself. A TIPC port is

automatically created whenever an application creates a TIPC socket by calling

socket( ) and specifying the

AF_TIPC address family. The application sends and

receives data through the socket, and TIPC routes the data through the associated

port. When the socket is closed, the associated TIPC port is deleted.

Data is sent through a TIPC socket in units called messages. A message is a

byte-array that can be from 1 to 66000 bytes long. The internal structure of the

message is determined by the application. A byte stream, connection-oriented

option,

SOCK_STREAM, is also available for stream data

Wind River TIPC allows messages to be exchanged in a reliable, connectionless

manner using the

SOCK_RDM socket type. It also supports the SOCK_DGRAM

socket type, which is essentially the same as

SOCK_RDM but does not guarantee

reliable message delivery. Applications can send messages using send( ),

sendmsg, or sendto( ); applications can receive messages using recv( ), recvfrom( )

or recvmsg( ).

Wind River TIPC allows messages to be exchanged over a reliable connection

using the

SOCK_SEQPACKET and SOCK_STREAM socket types. Two means of

establishing a connection are provided:

■

An application can issue an explicit connection request using connect( ). Once

the connection is accepted, it can send and receive messages using send( ).

■

An application can issue an implied connection request by sending a message

using sendto( ) without using connect( ). The connection is recognized as

completed when a response is received using recv( ), recvfrom( ), or

recvmsg( ).

This approach establishes a connection without requiring the connecting ports

to exchange handshaking messages prior to the exchange of data. It provides

the performance of connectionless data transfer and, since it is

connection-oriented, still guarantees a correlation between request and

response. An implicit connection request is particularly suitable when a client

needs to make a single request over a connection rather than a series of

requests.

To allow a socket to receive connection requests, an application first calls listen( ).

Then, to handle connection requests, the application calls accept( ). accept( ) waits

for a connection request and when it receives one, whether the request is explicit

or implicit, it creates a new socket that is connected to the requesting socket.

Once a connection is established, messages are typically exchanged using send( )

and recv( ) until one side terminates the connection by closing a socket.

2 TIPC Fundamentals

2.4 Message Reliability and Rejected Messages

Wind River TIPC makes considerable effort to successfully deliver a message to its

destination. For example, if a message is given to a Wind River TIPC link for

transmission to another node and then discarded by the underlying network

medium, the link detects the loss and retransmits the message. However, in some

cases, a message is undeliverable. This can occur because:

■

The specified destination does not exist.

■

The message was delivered to the specified destination, but the associated

socket was closed before it was received by the application.

■

The message was sent to a socket (or a node) that had too many unreceived

messages already in queue.

When Wind River TIPC is unable to deliver a message, it “rejects” it.

■

If a socket configured for connectionless but reliable message transfer

(

SOCK_RDM or SOCK_DGRAM, with the TIPC_DEST_DROPPABLE flag unset)

sends undeliverable messages, Wind River TIPC returns the first 1024 bytes of

each message to the originating socket.

■

If a socket configured for connection-oriented transfer (SOCK_STREAM or, if

TIPC_DEST_DROPPABLE (see setsockopt( )) is not specified,

SOCK_SEQPACKET) sends undeliverable messages, TIPC marks the first

undeliverable message sent to the destination as rejected and returns the initial

1024 bytes of the message. Subsequent undeliverable messages to the same

destination are discarded, since returning the first undelivered message

signals the socket that the connection is not functional.

■

If a socket is not configured for reliable message transfer, TIPC simply discards

undeliverable messages without informing the sender.

To receive rejected messages, an application can call the recvmsg( ) routine.

To decrease the likelihood that an important message is rejected because the

destination end is congested with unreceived messages, TIPC associates an

importance level with the messages sent by a socket. You can assign an importance

level by calling setsockopt( ) with its optname parameter set to

TIPC_IMPORTANCE. There are four importance levels:

■

TIPC_LOW_IMPORTANCE (default)

Messages are rejected at the first sign of congestion.

■

TIPC_MEDIUM_IMPORTANCE

Messages are rejected at medium levels of congestion.

■

TIPC_HIGH_IMPORTANCE

Messages are rejected only at high levels of congestion.

■

TIPC_CRITICAL_IMPORTANCE

messages are never rejected due to congestion.

NOTE: For all routines referred to in this chapter, see their API reference entries

for syntax statements and descriptions.

Wind River TIPC

Programmer's Guide, 1.7.6

2.5 TIPC Addressing

TIPC uses three different address forms within a network:

■

network address

■

physical port address

■

functional port address

2.5.1 Network Address

As mentioned previously, a TIPC network address has the form <Z.C.N>, where Z

is zone, C is cluster, and N is node. Depending on its value, it can apply to a specific

node, to any node within a cluster, or to any node within a zone. Network

addresses containing a zero, have special interpretations:

■

The network address <Z.C.0> applies to any node within cluster C.

■

The network address <Z.0.0> applies to any node within zone Z.

■

An isolated node that is not part of a TIPC network can be assigned a network

address of <0.0.0>. This prevents TIPC from allocating resources for

inter-node communication that will never be utilized.

Network address <0.0.0> can also be used as a lookup domain (see 2.5.4 Address

Resolution, p.14) rather than a node address.

Both Wind River TIPC and the open-source Linux version of TIPC interpret

network address <0.0.0> in the same way, which differs from the

interpretation in the draft TIPC specification.

An application specifies a network address using a 32-bit integer made up of three

fields:

■

Zone – 8 bits

■

Cluster – 12 bits

■

Node – 12 bits

Wind River TIPC provides the following APIs to allow applications to easily

manipulate network addresses:

■

tipc_addr( ) – takes separate values for zone, cluster, and node and combines

them into a TIPC address.

■

tipc_node( ) – takes a TIPC address and returns the node number.

■

tipc_cluster( ) – takes a TIPC address and returns the cluster number.

■

tipc_zone( ) – takes a TIPC address and returns the zone number.

2.5.2 Physical Addressing

A TIPC port has a unique port identity, which is automatically generated by TIPC

when the port is created. A port ID is made up of two components, the network

address of the node containing the port, in <Z.C.N> format followed by a colon,

and a 32-bit randomly generated reference value. Together, the two components

constitute the physical address of the port. The following is an example:

<1.1.7:1086734332>

2 TIPC Fundamentals

2.5 TIPC Addressing

An application can determine the port ID associated with a TIPC socket using the

getsockname( ) routine.

2.5.3 Functional Addressing

Most TIPC applications use functional addresses rather than port IDs when

communicating with TIPC sockets. A functional address allows the application to

exchange data with the desired socket without having to know the physical

location of the socket within the network. This makes it easy for applications to

continue processing even when the ports within a network are being created,

destroyed, or relocated dynamically; it also makes it easier for applications to

perform load sharing between multiple ports.

TIPC provides two forms of functional addressing: port name and port name

sequence.

A port name is made up of two 32-bit integers: a type and an instance. Typically, the

type field identifies the service provided by the port, while the instance identifies

some aspect of the service. For example, type 100 may indicate a printer, while

instance 500 of type 100 may identify a specific type of printer or the owner of the

printer.

An application can assign a port name any type value within the 32-bit range, with

the exception of types 0 through 63, which are reserved for TIPC-specific services.

Figure 2-3, section A, illustrates sending a request for a specific service (the port

name) to the socket providing the service. In section A, all the destination sockets

have port names assigned to them.

A port name sequence is made up of three 32-bit integers: a type, a lower instance,

and an upper instance. It provides a way to specify a sequential set of port names

using a single address, rather than having to specify the individual port names one

at a time.

A port name sequence is typically assigned to a socket when the socket is capable

of providing a series of related services. In Figure 2-3, section B illustrates sending

a request for a specific service in a context in which some destination sockets have

port name sequences assigned to them. Wind River TIPC allows a request to

contain a port name, as in Figure 2-3, but not a port name sequence. The TIPC

specification also allows port name sequences in requests for services.

Figure 2-3 Functional Addressing with Port Names and Port Name Sequences

type: 7

instance 12

type: 50

instance 1

type: 7

instance 1

send (type 7

instance 1)

type: 30

lower 7

type: 30

lower 1

send (type: 30

instance 5)

upper 15

upper 6

type: 18

instance 5

Wind River TIPC

Programmer's Guide, 1.7.6

To assign a functional address to a TIPC socket, an application calls bind( ) and

specifies a service (the port’s type) available through the socket and the scope

within which the service is available. The scope can include all nodes within the

socket’s node, cluster, or zone. Following a bind operation, TIPC automatically

sends (publishes) the new port-address information to all nodes within the

designated scope.

A functional address remains bound to a socket until the socket is closed or the

application calls bind( ) using a negative scope value (see the API reference

reference entry for bind( )). When the address is unbound, TIPC withdraws

publication of the address from the network.

2.5.4 Address Resolution

TIPC allows an application to bind multiple port names or port name sequences to

a single socket, unlike protocols such as TCP and UDP, which limit a socket to a

single physical address. This capability is most commonly used when a socket is

capable of providing multiple services.

TIPC also allows the same port name or port name sequence to be bound to

multiple sockets in a network. This is useful when the network contains more than

one socket that is capable of providing a given service.

TIPC does not allow port name sequences of a given type to have overlapping

instance values, unless the ranges match exactly, as illustrated by the following

examples:

If a given port name is bound to multiple sockets, an application should only use

a port name to request a service if it does not care what socket performs the service.

To request a service from a specific socket, the application needs to use the socket’s

port ID.

When a connection request or a message is sent to a port name, TIPC resolves the

name to a specific socket using the lookup domain specified by the message sender

as part of the port address. The lookup domain is specified in <Z.C.N> format.

Two name-resolution algorithms are available:

■

If the lookup domain is <0.0.0>, TIPC uses a closest-first algorithm: it first tries

to find a matching address belonging to a socket on the same node; if none

exists, it then searches the node's cluster and finally the node's zone. If TIPC

finds multiple matching addresses at a given level, it selects one in a

type 25

lower 1

upper 10

Valid port name sequences (non-overlapping instances):

type 25

lower 1

upper 10

type 25

lower 11

upper 100

type 25

lower 1

upper 10

type 30

lower 5

upper 55

type 25

lower 1

upper 10

Invalid port name sequences (overlapping instances):

type 25

lower 5

upper 15

type 25

lower 10

upper 10

剩余119页未读，继续阅读

weixin_40393589

粉丝: 0
资源: 2

WindRiver TIPC程序员指南：高效进程间通信

tipc_demo-1.15

tipc网络通讯协议栈源代码

集群服务器通信协议：TIPC简介

Tipc_Programmer_s_Guide.pdf

TIPC_Overview

Tipc Programmers Guide

tipc.rar_Be More_hayg3v_tipc

tipc.rar_Transformations

tipc.rar_interface

tipc.rar_The Don

最新资源