Tipc_Programmer_s_Guide.pdf_TIPC资源-CSDN文库

需积分: 9 86 浏览量 2019-03-20 08:49:40 上传评论收藏 98KB PDF 举报

资源推荐

资源详情

资源评论

TIPC Programmer's Guide

=======================

Version 1.2.1 (19 September 2006)

This document is intended to assist software developers who are writing

applications that use TIPC. For information about setting up and operating a

network that supports TIPC please see the TIPC User's Guide.

ADVISORY:

Many topics discussed in this document are presented in a very compact format,

which presents as much information as possible in as few words as possible.

Readers will gain the most benefit from this document by carefully reading

(and re-reading) the material, as this will provide a better understanding of

TIPC than is likely to be obtained by quickly skimming through it.

Table of Contents

-----------------

1. TIPC Fundamentals

2. Socket API

3. Native API

4. FAQ

5. Tips and Techniques

1. TIPC Fundamentals

--------------------

A brief summary of the major concepts is provided in the following sections.

For a comprehensive description of TIPC, please consult the latest version of

the TIPC specification at http://sourceforge.net/projects/tipc.

IMPORTANT:

At the time of this writing, the TIPC specification has not been updated to

include the latest modifications incorporated into TIPC version 1.5 (or

later). In cases of conflict between the specification and this document,

the information in this document takes precedence.

1.1 TIPC Network Structure

--------------------------

Conceptually, a TIPC network consists of individual processing elements or

"nodes". A set of related nodes form a "cluster", while a set of related

clusters form a "zone". Typically the grouping of nodes into clusters and

zones is based on location; for example, all nodes in the same shelf or the

same room may be assigned to the same cluster, while all clusters in the same

building may be assigned to the same zone.

Each node in a TIPC network is assigned a unique network address consisting

of a zone, cluster, and node identifier, usually denoted <Z.C.N>. Each of

these identifiers is an integer value in the range from 1 to the maximum

value defined by the network administrator. (Exception: A TIPC node which is

not yet part of a larger network uses the default network address of <0.0.0>

until a real network address is assigned.) By default the maximum values for

zone, cluster, and node identifiers are 3, 1, and 63, respectively, while the

theoretical maximums are 255, 4095, and 2047, respectively.

A TIPC node is also assigned a "network identifier". This allows multiple

TIPC networks to use the same physical medium (for example, the same Ethernet

cables) without interfering with one another -- each node only recognizes

traffic originating on nodes having the same network identifier.

Nodes in a TIPC network communicate with each other by using one or more

network interfaces to send and receive messages. Each network interface must

be connected to a physical medium that is supported by TIPC (such as

Ethernet). When properly configured, TIPC automatically establishes "links"

to enable communication with the other nodes in the network, and takes care

of routing traffic over the appropriate link, retransmitting messages in the

event of errors, etc.

THINGS TO REMEMBER:

- TIPC network addressing is NOT like IP network addressing!!! There is only

one network address per node in TIPC, even if the node has multiple network

interfaces. A node's network interfaces are NOT assigned network addresses

at all.

- The network administrator takes care of assigning the network address and

the network identifier for each node in the network, so programmers don't

have to worry about this.

- The network administrator also takes care of configuring each node's

network interfaces to enable communication with all other nodes in the

network, so programmers don't have to worry about this either.

CURRENT LIMITATIONS:

- TIPC only supports a single cluster per zone.

- TIPC does not support inter-zone communication, so nodes in different zones

are effectively part of distinct networks even if they have the same network

identifier.

- TIPC does not support the "secondary nodes" concept mentioned in the

specification document.

1.2 Messaging Overview

----------------------

Applications in a TIPC network typically communicate with one another by

sending data units called "messages" between communication endpoints called

"ports".

From an application's perspective, a message is a byte string from 1 to 66000

bytes long, whose internal structure is determined by the application. A

port is an entity that can send and receive messages in either a connection-

oriented manner or a connectionless manner.

Connection-oriented messaging allows a port to establish a connection to a

peer port elsewhere in the network, and then exchange messages with that

peer. A connection can be established using an explicit handshake mechanism

prior to the exchange of any application messages (a variation of the SYN/ACK

mechanism used by TCP) or an implicit handshake mechanism that occurs during

the first exchange of application messages. Once a connection has been

established it remains active until it is terminated by one of the ports, or

until the communication path between the ports is severed (for example, by

the failure of the node on which one of the ports is running); TIPC then

immediately notifies the affected port(s) that the connection has terminated.

Connectionless messaging allows a port to exchange messages with one or more

ports elsewhere in the network. A given message can be sent to a single port

(unicast) or to a collection of ports (multicast), depending on the destination

address specified when the message is sent.

TIPC is designed to be a reliable messaging mechanism, in which an application

can send a message and assume that the message will be delivered to the

specified destination as long as that destination is reachable. If a message

cannot be delivered the message sender can specify whether it should be returned

to its point of origin or discarded, according to the needs of the application.

(See the section on "Message Delivery" that appears later in this document for

more information.)

THINGS TO REMEMBER:

- In a TIPC network where different nodes may be running on different CPU

types and/or operating systems applications must ensure that the internal

structure of a message is well-defined, and accounts for any differences in

message content endianness, field size, and field padding.

1.3 TIPC Addressing

-------------------

TIPC uses 3 distinct forms of addressing within a network.

1.3.1 Network Address

---------------------

The network address was introduced in section 1.1, and is typically denoted

as <Z.C.N>. Applications use this address format with certain operations to

specify the portion of a TIPC network the operation applies to:

a) <Z.C.N> indicates a network node

b) <Z.C.0> indicates a network cluster

c) <Z.0.0> indicates a network zone

d) <0.0.0> has special meaning, which is operation-specific

When coding, a network address is represented as an unsigned 32-bit value,

comprising 3 fields: an 8-bit zone field, a 12-bit cluster field, and a 12-

bit node field. (See section 1.6 for a description of routines for

constructing and deconstructing networks addresses.)

1.3.2 Port Identifier

---------------------

Each port in a TIPC network has a unique "port identifier" or "port ID",

which is typically denoted as <Z.C.N:ref>. The port ID is assigned

automatically by TIPC when the port is created, and consists of the 32-bit

network address of the port's node and a 32-bit reference value. The

reference value is guaranteed to be unique on a per-node basis and will not

be reused for a long time once the port ceases to exist.

1.3.3 Port Naming

-----------------

While a TIPC port can send messages to another port by specifying the port ID

of the destination port, it is usually more convenient to use a "functional

address" that does not require the sending port to know the physical location

of the destination within the network. This simplifies communication when

server ports are being created, deleted, or relocated dynamically, or when

multiple ports are providing a given service.

The basic unit of functional addressing within TIPC is the "port name", which

is typically denoted as {type,instance}. A port name consists of a 32-bit

type field and a 32-bit instance field, both of which are chosen by the

application. Typically, the type field is used to indicate the class of

service provided by the port, while the instance field can be used as a sub-

class indicator.

Unlike port IDs, port names need not be unique within a TIPC network.

Applications are permitted to assign a given port name to multiple ports, and

to assign multiple port names to a given port, or both. Port names can also

be unbound from a port if they are no longer required.

Whenever an application binds a port name to a port, it must specify the level

of visibility, or "scope", that the name has within the TIPC network: either

"node scope", "cluster scope", or "zone scope". TIPC then ensures that only

applications within that portion of the network (i.e. the same node, the same

cluster, or the same zone) can access the port using that name.

To simplify the task of specifying a range of similar port name instances

TIPC supports the concept of the "port name sequence", which is typically

denoted as {type,lower bound,upper bound}. A port name sequence consists

of a 32-bit type field and a pair of 32-bit instance fields, and represents

the set of port names from {type,lower bound} through {type,upper bound},

inclusive. The lower bound of a name sequence cannot be larger than the

upper bound.

There are a number of restrictions on port naming that programmers need to

be aware of.

1) The type values from 0 to 63 are reserved by TIPC and cannot be used to

designate an application service.

2) Port names and name sequences are designed for use by server ports. TIPC

does not allow a named sever port to initiate a connection (as if it were a

client port), nor does it allow the assignment of names to a connected client

port (as if it were a server port).

3) TIPC does not currently allow the creation of partially overlapping port

name sequences (unless the name sequences cannot be seen simultaneously). For

example, once a node has a port having the name sequence {100,1000,2000} --

or the node is notified that another node has a port with this name sequence --

it cannot then assign the name sequences {100,500,1200} or {100,1100,1500}

to any of its ports; however, the node is permitted to assign {100,1000,2000}

to other ports or to use name sequences having other type values such as

{150,500,1200}. Overlapping name sequences *are* permitted if they are

published by different nodes and are published with non-overlapping scopes;

for example, you can publish {100,500,1200} on node <1.1.1> and {100,1100,1500}

on node <1.1.2> as long as they both are published with node scope.

THINGS TO REMEMBER:

- Programmers typically only have to worry about the selection of TIPC names

and name sequences. (Network addresses are chosen by the TIPC network

adminstrator, while port ID's are chosen by TIPC automatically.)

- Well-known names (or name sequences) are used in a TIPC network in the same

way that well-known port numbers are used in an IP network.

- An application must use TIPC names (or name sequences) that do not conflict

with the names used by other applications.

1.4 Using Port Names

--------------------

This section discusses more advanced aspects of TIPC's functional addressing.

1.4.1 Address Resolution

------------------------

Whenever an application specifies a port name as the destination address of a

message, it must also indicate where within the network TIPC should look to

find the destination by specifying a "lookup domain".

The most commonly used lookup domain is <0.0.0>, which tells TIPC to use a

"closest first" approach. TIPC first looks on the sending node to find a port

having the specified port name; if more than one such port exists, TIPC selects

one in a round-robin manner. If the sending node does not contain a matching

port, TIPC then looks to all other nodes in the sending node's cluster to see

if any ports have published that name using cluster scope or zone scope; again,

if more than one such port exists, TIPC selects one in a round-robin manner.

Finally, if no matching port is found within the sending node's cluster, TIPC

looks at all other nodes in the sending node's zone for ports with a matching

name and having zone scope, and selects one in a round-robin manner. (In short,

address resolution is performed using 3 lookup domains in succession: first

using <Z.C.N>, then <Z.C.0>, and finally <Z.0.0>.) This algorithm results in

the message being delivered to a suitable destination as quickly as possible,

and also load sharing similarly named messages among all such destinations at

the same distance from the sender.

Alternatively, an application can specify a single lookup domain to be used

for address resolution. Specifying a lookup domain of the form <Z.C.N>,

<Z.C.0>, or <Z.0.0> tells TIPC to take all ports with compatible name and scope

values within the specified node, cluster, or zone, respectively, and then

select one in a round-robin manner. These forms can be useful in preventing

a message from being sent off-node, or for evenly distributing work to all

servers scattered throughout a cluster or zone.

It should be noted that the round-robin selection mechanism used by TIPC is

shared by all applications using a given node. So, for example, if there are

two ports within the specified lookup domain that have the desired port name,

an application cannot assume that two successive messages it sends to that name

will be distributed one to each port. This is because a similarly named message

sent by another application may arrive in the interim, thereby causing the

second message sent by the first application to go to the same destination as

its first message.

1.4.2 Multicast Messaging

-------------------------

Whenever an application specifies a port name sequence as the destination

address of a message (rather than a port name), this instructs TIPC to send a

copy of the message to every port in the sender's cluster that has at least one

port name within the destination name sequence.

This is most easily illustrated using an example. Suppose a multicast message

is sent to {1000,100,200}, then the following ports will each receive exactly

one copy of the message:

<1.1.10:1234> having {1000,100} - one matching name

<1.1.11:4321> having {1000,123} and {1000,175} - two matching names

<1.1.10:5678> having {1000,150} and {2000,150} - non-matching name ignored

<1.1.12:5555> having {1000,110,120} - subset overlap

<1.1.10:8888> having {1000,50,500} - superset overlap

<1.1.14:9999> having {1000,170,300} - partial overlap

while the following ports will not receive a copy at all:

剩余25页未读，继续阅读

评论收藏

内容反馈

这个书生有点意思

粉丝: 39
资源: 114

Tipc_Programmer_s_Guide.pdf

tipc_programmers_guide

tipc_demo-1.15

tipc网络通讯协议栈源代码

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

Android - A Programmer's Guide.pdf

权威EOS6.0.Programmer.Guide.pdf

VxWork Kernel Programmer's Guide 6.2.pdf

VxWorks_7_Programmer_s_Guide__SR0620.pdf

DLPC300 Software Programmer's Guide.pdf

TIPC_Overview

eth_media.rar_tipc

tipc.rar_interface

tipc.rar_Be More_hayg3v_tipc

SpiiPlus_C_Library_Programmer_Guide.pdf

CX-Programmer Introduction Guide.pdf

DLPC34xx Software Programmer’s Guide.pdf

Perl Programmer's Reference Guide.pdf

SPiiPlus C Library Reference Programmer Guide.pdf

算法shell的输出结果

tipc.rar_Transformations

tipc.rar_The Don

net.rar_tipc

msg.rar_tipc

VxWorks Programmer's Guide.pdf

VxWorks__7_Programmer_s_Guide.pdf

ILE RPG Programmer's Guide.pdf

HX3313_Programmer_Guide_V04.pdf

BPS.6.0.Programmer.Guide.EOS.Dev.pdf

TIPC-700嵌入式触摸平板电脑产品简介.pdf

最新资源