talarian : everything you need to know about middleware

Talarian™: EverythingYou Need To KnowAbout Middleware

A Guide To Selecting A Real-Time Infrastructure

1 Everything You Need To Know About Middleware

ContentsContents 1

Executive Summary 3

What is Middleware? 4

Specialized Kinds of Middleware 5Transaction Processing Monitors 5

Remote Procedure Calls (RPCs) 5

Object Request Brokers 6

Homegrown Middleware 6

Message-Oriented Middleware 6

Message Queuing 6

Message Passing (Publish-Subscribe) 7

Java Message Service (JMS) 7

The Middleware Market 8

Key Features of Modern Middleware 9Challenges of Network Programming 9

Encoding the Information 9

Data Translation 10

Multi-Protocol Support 10

Finding Resources 10

Flow Control 10

Portability and Standards Issues 10

Asynchronous Operation 10

Configuring Resources/Programs on the Network 10

Dealing with Hardware or Software Failures 10

Managing Multiple Clients and Servers 11

Changing Environment 11

Debugging and Analysis 11

SmartSockets®: An In-Depth Look 12

A Guide To Selecting A Real-Time Infrastructure 2

High-Speed Interprocess Communication 12

Publish-Subscribe Services 13

Peer-to-Peer Communication 13

Multicast 13

Asynchronous Messaging 13

Synchronous Messaging 13

Thread Safe 14

High Availability and Reliability 14

Quality of Service 14

Dynamic Message Routing 14

Multiple RTserver™ Processes 14

Distributed Application Monitoring, Administration, and Debugging 15

Graphical Interface 15

Monitoring Interface 15

Message Logging 16

Platform and Protocol Independence 16

Automatic Data Translation 16

Platform Support 16

Protocol Driver 16

Powerful Message Handling 16

Automatic Message Buffering and Flow Control 17

Prioritized Message Queues 17

Reusable and Extensible Message Types 17

Load Balancing 17

Scalability 17

Benefits of SmartSockets 19Increased Productivity 19

Reduced Risk 19

Increased Scalability 19

Protected Investment in Hardware and Software 19

Reduced Maintenance Cost 19

Increased Application Availability 19

More Productive Use of Resources 20

Getting Started with SmartSockets 21Example C Programs 21

3 Everything You Need to Know About Middleware

Executive SummaryIn today’s real-time world, businesses need toexchange information instantly, reliably and securelywith customers, partners and suppliers around theglobe via the Internet. Because this involves complexapplications running across multiple platforms usingdata distributed across the enterprise, forwardthinking CIOs and enterprise architects are findingmiddleware to be the core infrastructure on which tobuild their applications.

For years, middleware has been used to handle datamovement across disparate platforms and betweenincompatible databases. In addition, middleware hasmade it easy for developers to handle the differencesbetween platforms and databases by writingapplications that connect to the middleware layer andby letting the middleware handle the data translationand transport.

This model has proved itself extensively, and manylarge sites rely on middleware for truly mission-critical applications. In today's world though,middleware must do more. Not only must it provide auniform interface to disparate systems, but it alsomust serve as the fundamental corporate datatransport, both within the enterprise and between theenterprise and the Internet. Hence, middleware todayneeds to be robust enough to handle the message loadof the busiest sites in real-time while providingguaranteed delivery of messages throughout theenterprise.

Several types of middleware provide targetedsolutions for this problem. Transaction processing

monitors, for example, provide data integrity fordatabase transactions. Object request brokershandle the interaction of objects—such as thosein C++ and Java—across disparate platforms.And specialized services, such as JavaMessage Service (JMS), help provide tailoredsolutions to unique problems. The coremiddleware, which is a superset of all thesemodels, is message-oriented middleware(MOM). By use of messages, MOM enables allforms of communication between programs—beit transaction processing, object sharing, or Javacommunication—to occur between any twopoints in the enterprise.

Talarian's SmartSockets product implementsMOM within the constraints of high-speed, real-time message delivery. SmartSockets is alsoknown for its scalability: it can be deployed on asmall network of a few nodes or a network ofthousands of clients who need to share real-timedata broadcasts in a secure environment wheremission-critical reliability is a must.SmartSockets is also deployed at numerous siteswhere the real-time aspect is not paramount butwhere enterprise system architects want amessaging infrastructure that does not consumelarge amounts of bandwidth but is still capable ofspanning a wide variety of platforms and clientswithout difficulty.

The rest of this pamphlet discusses the types ofmiddleware available today, the strengths ofeach, and the best applications for each kind. Itthen explains Talarian's SmartSockets in depth.


What is Middleware?As the distributed model of enterprise computinghas become more common, the term middlewarehas acquired numerous meanings that would allowit to be just about any piece of software that sitsbetween systems. Terms such as enterpriseapplication integration (EAI) and extensible mark-up language (XML) often are mistakenly used todescribe middleware.

In the strict sense, middleware is transport softwarethat is used to move information from one programto one or more other programs, shielding thedeveloper from dependencies on communicationprotocols, operating systems, and hardwareplatforms. Middleware provides the “plumbing”necessary for applications to exchange data,regardless of the environment in which they arerunning. Transactions, data broadcasts, EAIpackages, and XML data often ride on middlewarein the enterprise.

The concept of middleware dates back to the 1980swhen companies wanted one package to move databetween mainframes, databases, and userterminals. Modern middleware extends thisconcept to the widespread distribution of data inreal time across a remarkable variety of servers,clients, and sites.

Middleware as used in this sense tends to bemessage-oriented. That is, data is sent betweensystems in messages, which are similar to datapackets on the network. These messages haveheaders that indicate the destination and payloadsof varying sizes and formats that contain the actual

data. Message-oriented middleware (or MOM)originally appeared in the form of message queues.

When a message was sent to another system, it wasstored in a message queue on the destinationsystem. Whenever the destination system neededthe data, it looked in the queue for the message. Ifit was there, the message was retrieved; if not, thesystem would wait until the data arrived in thequeue. This approach proved reliable, but slow. Itstill is used today in many transaction-orientedenvironments, where security of transactions andintegrity of message delivery is a high priority.A second model, called publish and subscribe (orpub/sub), evolved from the need to delivermessages in real time, especially to a large numberof clients. In the pub/sub model, clients register forcertain kinds of messages they are interested in,and a server sends the clients those messages inreal time. The emphasis of the pub/sub model is tosend data from one server to many clients as fast aspossible. Typical applications might bestockbrokers needing the latest prices on certainbonds or equities. These prices typically are sent inreal time to all brokers who subscribe to thisinformation.

One company today, Talarian Corp., combines thetwo models of MOM: its product SmartSocketsdelivers messages in real time with the reliabilityand integrity of message queuing. In fact,SmartSockets can be installed as either a pub/subimplementation or a message-queuing package.


Specialized Kinds ofMiddlewareThe previous section briefly introduced the twotypes of message-oriented middleware. Other typesof middleware are commonly found todayperforming narrow functions.

The middleware market can be broken into fivedifferent segments:

1. Transaction processing monitors2. Remote procedure calls3. Object request brokers4. Homegrown middleware solutions5. Message-oriented middleware (MOM)

Transaction ProcessingMonitorsTypically, transaction-processing (TP) monitors arenot used for general purpose program-to-programcommunication. Rather, they provide a completeenvironment for transaction applications thataccess relational databases.

In TP monitors, clients invoke remote proceduresthat reside on servers, which also contain a SQLdatabase engine. Procedural statements on theserver execute a group of SQL statements(transactions), which either all succeed or all fail asa unit. The applications based on transactionservers are called on-line transaction processing(OLTP). They tend to be mission-criticalapplications that require a rapid response 100% ofthe time and tight controls over the security andintegrity of the database.

The communication overhead in this approach iskept to a minimum because the exchange typicallyconsists of a single request/reply (as opposed to themultiple SQL statements required in databaseservers).

TP monitors provide application development tools(such as user interaction and database interfaces),system administration (such as security and

tuning), and transaction execution (such asscheduling and load balancing).

X/Open, a vendor-neutral standards group, hasdone a considerable amount of work towarddefining a process model and related servicesinterfaces for distributed processing applications.Most vendors have pledged to support some ormost aspects of the X/Open model.

TP monitors should be considered whentransactions need to be coordinated andsynchronized over multiple databases. TP monitorstend to be heavyweight and expensive, and theyrequire a great deal of expertise to implementproperly. Most TP vendors have a large serviceside to their business.

Remote Procedure Calls(RPCs)RPCs have been around for a long time. They areone of the earliest forms of interprogramcommunication, and they operate at a very lowlevel. From a programmer’s point of view, RPCsare easy to understand. The code invokes aprocedure that is located on a remote system, andthe results are returned. Generally, the applicationcomponents communicate with each othersynchronously, meaning they use a request/wait-for-reply model. RPCs work well for smaller,simple applications where communication isprimarily point-to-point (rather than one system tomany). RPCs do not scale well to large, mission-critical applications, as they leave many crucialdetails up to the programmer, such as thefollowing:

1. handling network or system failures2. handling multiple connections3. portability4. buffering and flow control5. synchronization between processes


Due to their synchronous nature, RPCs are not agood choice to use as the building blocks forenterprise-wide applications where highperformance and high reliability are needed. TheRPC standards have not evolved in any significantway during the last five years, primarily because ofthe emergence of the Object Request Brokersdescribed in the next section.

Object Request BrokersObject Request Brokers (ORBS) can be thought ofas language-independent, object-oriented RPCs.There are two competing standards for ORBs:

1. CORBA, backed by more than 700companies from the Object ManagementGroup (OMG)

2. DCOM, backed by Microsoft

(Java’s Remote Method Invocation (RMI) could beconsidered an ORB, although it is useful primarilyfor facilitating communication between twoprograms written in Java and does not addressother programming languages as do both DCOMand CORBA.)

ORBs are designed for use in projects that require astrict object-oriented approach, where “objects arethe only way.” Like RPCs, ORBs are generallysynchronous and operate in a point-to-pointmanner. In general, both CORBA and DCOMassume the system has a reliable communicationslayer, and they do not address the problemsinvolved when this layer is not reliable.

Early on, the OMG recognized that CORBA’srequest-reply communication was not going to beadequate for building true, enterprise-wide,mission-critical applications. Some of the CORBAvendors added proprietary extensions to theirproducts to address these shortcomings. The OMGspecified the CORBA Event Service, a standard setof services layered on top of CORBA, whichbrought most of the vendor extensions into theCORBA model. In 1998, the OMG approved theAsynchronous Messaging Service. However, thisfacility is not widely used in CORBA deploymentstoday.

Homegrown MiddlewareWhen companies first encounter the need for amiddleware layer, they often have a specificproblem to address that requires a modest solution.Rather than invest in a middleware package,

smaller firms will allow their own developmentstaff to write a middleware-like solution to solvethe particular problem. Although initiallyworkable, this approach tends to lack scalabilityand flexibility as new problems have to dovetailwith the old solution. As a result, supporting thehomegrown middleware becomes expensive as ithas to be customized and extended constantly—generally by staff members who have never writtenmiddleware software before. The final result is anexpensive solution that tends to break easily anddoes not scale well.

Message-OrientedMiddlewareIn general, MOM products work by passinginformation in a message from one program to oneor more other programs. The information can bepassed asynchronously, where the sender does nothave to wait for a reply. MOM products, ingeneral, cover more than just passing information;they usually include services for translating data,security, broadcasting data to multiple programs,error recovery, locating resources on the network,cost routing, prioritization of messages andrequests, and extensive debugging facilities. Unlikeboth ORB and RPC products, MOM, in general,does not assume the system has a reliable transportlayer underneath. MOM tries to address theproblems that surface when the transport layer isunreliable, as occurs when programs mustcommunicate over a WAN or over the Internet.

Two different types of MOM have emerged:

1. message queuing2. message passing

Message Queuing

In message queuing, program-to-programcommunications occur via a queue, which istypically a file. It allows programs to send andreceive information without having a directconnection established between them. A programsimply gives messages to the message queuingservice, identifying by name the queue in which itwishes the message to be placed. The messagequeuing service acts as an intermediary, and themechanism by which the message is transmitted iscompletely hidden from the application programs.In large, enterprise-wide applications, queues canbe set up to forward the messages to other queues.Message queuing provides safe storage ofinformation and is most appropriate where


applications cannot be connected directly (forexample, in mobile computing). However, messagequeuing tools require considerable configuration toset up correctly and performance can be poor. Ifaccess to a queue is lost for any reason, the entiresystem can be affected.

Message Passing (Publish-Subscribe)

Message passing has proven popular for buildinglarge, distributed applications. This approachdiffers from message queuing in that rather thanoblige applications to retrieve the information theyrequest, the information is more efficiently pushedto the interested parties. One increasingly popularflavor of message passing uses a model ofcommunication known as publish-subscribe(pub/sub). In pub/sub, programs subscribe to(register interest in) a subject. Programs alsopublish (send) messages to the subject. Once asubject has been subscribed to by a program, theprogram will receive any messages published tothat subject in the distributed application. Subjectsare defined by the application developer.

In traditional network applications, when twoprocesses must communicate with each other, theyneed network addresses to begin communicating. Ifa process wants to send a message to many otherprocesses, it first would need to know the physicalnetwork addresses of the other processes and thencreate a connection to all those processes. Thisarchitecture does not scale well because config-uration is complicated and tedious. The publish-subscribe communications model provides locationtransparency, allowing a program to send themessage with a subject as the destination property

while the middleware routes the message to allprograms that have subscribed to that subject.

MOM vendors typically implement publish-subscribe with a set of agents that maintain a real-time database, listing which programs areinterested in which subjects. A program publishes amessage by connecting with one of the agents (itmay or may not be on the same machine) andsending the message to it. The agent then routes themessage to the appropriate programs. Often, thepub/sub middleware has greater fault tolerancebecause the agents can perform dynamic routing ofthe messages as well as provide hot fail overshould any of system fail. Pub/sub is mostappropriate for highly distributed applicationswhere fault tolerance and high performance areimportant. It does not work well in situations whereprocesses may be disconnected from the networkfor long periods of time.

Java Message Service(JMS)The JMS is a specification published by JavaSoft,the division of Sun Microsystems responsible fordeveloping and managing the Java language. Itspecifies a set of programming interfaces by whichJava programs can access MOM software. MostMOM vendors today have announced they intendto support JMS in future releases, while a fewleading-edge vendors, such as Talarian, alreadyhave implemented support for JMS in theirproducts.


The MiddlewareMarketDue to the incursion of the Internet into enterprise computingand the corresponding move to a distributed-computing model,the middleware market has seen tremendous growth during thepast several years. Most analysts expect this growth to continueunabated through the early years of this decade.

Technology Forecast: 2000 from PricewaterhouseCoopersquotes a Dataquest survey of 547 IT shops and their buyingplans for all forms of middleware. (See Figure 1.) The type ofmiddleware that the largest number of sites expects to purchaseis MOM. During the period from 1998 to 2003,PricewaterhouseCoopers expects the MOM market to grow at acompound annual growth rate (CAGR) of 19.6%

Talarian is recognized in the same report as a key innovator andone of the leading vendors of MOM software. And indeed, since1988 Talarian has been leading the field in the delivery of real-time MOM infrastructure.

0 50 100 150 200

MOM

TPMs

ORBs

Other

None

Figure 1. Types of middleware most IT sites are likely to purchase.(Source Dataquest, quoted by PricewaterhouseCoopers)


Key Features ofModern MiddlewareToday’s mission-critical systems make extensive useof distributed computing to share information overlarge, heterogeneous networks. At the heart of thesemission-critical systems is the difficult task ofpassing information reliably between manyapplications running on different computers. Today’sIT environment often includes a mix of mainframes,UNIX workstations, and PCs trying to communicateover multiple network protocols.

The need for distributed applications runs the gamutfrom the classic commercial replication of a databaseto today's more exotic push technologies whereselected information is pushed out over the Internetin real time to interested subscribers. There areincreasing amounts of information being madeavailable and ever greater demands for instant accessto the information. In many applications, highvolumes of information (often passed in messages)must be distributed throughout the network.Examples of such applications include the real-timecollection, monitoring, and distribution of data fromsources such as factory floors all the way to the datacenters where inventory, order entry, and personnelinformation is kept.

Historically, the communication infrastructure forthese distributed applications was built in-houseusing low-level interprocess communicationprimitives such as sockets, pipes, shared memory,RPCs, and sometimes even files. Information wastypically encoded in a structured packet ofinformation called a message (not to be confusedwith an e-mail message). These home-brewedsolutions were relatively straightforward to developfor very small applications running on LANs. But asthe distributed applications grew larger and moreheterogeneous, using these primitive mechanismsbecame less attractive because of the myriadcomplexities to deal with. In-house solutions arestarting to break as the complexity of the networkgrows and the software is being used on ever moredemanding applications.

Challenges of NetworkProgrammingThe term network programming is used to definethe software development process of buildingapplications that must communicate with oneanother over a network such as a LAN, WAN oreven the Internet. No matter what the nature ofthe application, establishing program-to-programcommunication that operates reliably over anetwork using sockets, shared memory, RPCs orsome other interprocess communicationmechanism is an arduous task. Networkprogramming can be a software developer'sworst nightmare. In projects involvingdistributed applications, building the interprocesscommunication is often the most difficult andrisky part and often the cause of behind scheduleand over budget client/server applications.

With the number of mission-critical distributedsystems growing rapidly, a new market hasemerged for off-the-shelf middleware.

Before IT managers can identify the rightmiddleware solution, they must understand thedifficult challenges of network programming.The following reveals and clarifies thosechallenges.

Encoding the Information

Information that is passed from one program toone or more other programs must be encoded(formatted) in a manner that all the participatingprograms understand. Upon receipt of theinformation, programs must know how to accessand decode. If developers are using RPCs or an(ORB), the encoding/decoding rules are definedin an interface definition language. Some otherforms of middleware use self-describingmessages in which the sending and receivingprocesses do not need to be tightly coordinatedto exchange information. Upon receipt of the


message, the message itself can be queried tounderstand how it has been encoded.

Data Translation

As information is passed across the network, it oftenwill go from one type of platform (for example, SunSPARC) to another type (such as Intel x86 PCs).Often, the platforms will not have compatible formatsfor representing different types of data such asfloating point numbers and text strings. The networkprogrammer must translate the different types so theyare understood by the receiving processes. Ideally,this translation should be completely transparent anddone only one time, at the final destination (receivermakes right).

Multi-Protocol Support

Today's distributed computing environments usemany different network protocols, including TCP/IP,IBM’s SNA, multicast, Digital’s DECnet and manyothers. Information moving from one program toanother across the network may need to betransferred from one protocol to another; this iscalled context bridging.

Finding Resources

To build a large, distributed application, manyresources (for example, processes) must be tracked.For these resources to share information, they oftenneed to know each other's location and how tocommunicate. The location of the resources changesfrequently as new applications and new servers arebrought online. The ability to find and track resourcesis often called naming services.

Flow Control

In a distributed application, programs are sometimesunable to keep up with the flow of information, orthey can be busy doing something else wheninformation arrives. This can cause programs andcomplex applications consisting of multiple programsto get out of sync and potentially use large amountsof system resources, such as memory or CPU.Developing software to handle varying traffic ratescan be a complex task.

Portability and Standards Issues

There are few standards for passing informationacross a network. The few existing standards oftenconflict with one another. Some of the existingstandards include sockets, streams, named pipes,RPCs, and ORBs. Even at this level, there are oftenmultiple, competing standards. For example, there areseveral different versions of RPCs, including ONCand DCE. Examples of ORBs are OMG’s CORBAand Microsoft’s COM/OLE. Even Java’s RMI could

be considered an ORB. Lower-level interprocesscommunications (IPC) socket primitives includeBerkeley UNIX sockets, UNIX System Vsockets, and Winsock. Berkeley sockets, whichare supported on many different platforms, oftenhave small, subtle differences across differentflavors of UNIX operating systems. Winsock issimilar to Berkeley sockets, but contains somesignificant differences.

Asynchronous Operation

In a distributed application, a program oftenneeds to send information without waiting for areply. This implies that the reply will come fromone or more of the receiving programs at someindeterminate time in the future. Working in anasynchronous environment makes the job of thenetwork programmer more difficult.

Often, programming mechanisms such ascallbacks are used to handle asynchronousbehavior. These are functions that are executedwhen a specific type of event occurs (forexample, a reply arriving). Another commonway to achieve asynchronous operation isthrough the use of threads, where a program mayhave multiple threads sending and receiving overa single connection. This implies the middlewareused must be thread-safe.

Configuring Resources/Programs on theNetwork

In a distributed computing environment,uniquely identifying a machine or program oftenis done through a complex numbering or namingscheme. For TCP/IP networks, IP addresses ofthe form xxx.xxx.xxx.xxx are used to uniquelyidentify a machine. Network programmers mustunderstand and use these arcane facilities whenbuilding their applications. Reconfiguring anapplication when a machine is added or removedfrom the network can be complex because sourcecode may need to be changed and the entireproject may be required to go through anothercycle of integration and test.

Dealing with Hardware or SoftwareFailures

One major problem facing today's client/servercomputing environments is the higher likelihoodthat some component of the application will failor partially fail: the network, a machine, or aprogram on a machine. Recovering from suchfailures can be difficult. Often, completerecovery is not possible, and the application mustgracefully degrade as resources are lost.


Therefore, fault tolerance is an important feature ofany solution.Even detecting something as simple as a networkfailure is often protocol dependent. TCP/IP wasdesigned to hide errors and try to correct themwithout any intervention. It does a very poor job ofinforming the programmer when errors occur.Generally, TCP/IP will let the programmer knowonly about unrecoverable errors, and it is not unusualfor minutes to go by before TCP/IP reveals it has aproblem. Without some type of proactive approach,recovery from such problems is almost impossible.This is not acceptable for most of today's mission-critical applications.

Managing Multiple Clients and Servers

In a distributed application, there can be manyprograms exchanging information over manyconnections. Often, a program wishes to send amessage to multiple receiving programs, all with asingle operation. Other times, a program would liketo send a message to the “least busy” of a specifiedset of programs in order to get a quick reply.Coordinating multiple programs running across aheterogeneous network can be a difficult job for anetwork programmer.

In managing multiple clients and servers, ITprofessionals have to be careful in the use of networkbandwidth to keep all the programs coordinated. Acommon problem is flooding the network withinformation whenever some type of change occurs tothe distributed system (for example, a program startsor stops). Whenever this happens, a large amount ofnetwork chatter can occur, which can use largeamounts of network bandwidth and put the system inan inconsistent state until the change has beenpropagated.

Changing Environment

The network environment on which the distributedapplication executes changes quite frequently. Newcomputers are brought in to replace old computers orto add more capacity to the enterprise. New networkequipment—such as bridges, routers, and switches—is added to make more efficient use of the network.Even interfaces between the software programschange as the scope of the distributed system evolvesover time. This dynamic environment can wreakhavoc in even the best-designed systems.

Some types of middleware have great difficultyhandling these changes. Middleware thatdepends on an interface definition language, suchas ORBs and RPCs, relies heavily on staticdefinitions that will not change. Changes to theinterface require changes to the interfacedefinition and the recompilation and relinking ofthe code. The OMG’s CORBA has defined adynamic invocation interface (DII) to handle thisproblem. In practice, few developers use the DIIbecause it is very difficult to understand andprogram.

Publish-subscribe middleware uses the idea ofsubjects to handle the frequent reconfiguration ofa distributed application. Changes to theinterfaces between programs are handled by self-describing messages, whose definition maychange on-the-fly.

Debugging and Analysis

Distributing programs across a network canprovide large benefits to an organization—supplying real-time information to userswhenever and wherever they need it. Thepayback in productivity and quality realized bythe organization can be enormous.Unfortunately, building distributed applicationsis difficult, and trouble-shooting and debuggingproblems have the potential to disrupt criticalelements of the operation when theseapplications experience failures.

Effectively debugging a distributed applicationrequires fine-grained visibility into thecommunication between programs. In general,the primitive interprocess communication (IPC)mechanisms provided by operating systemsnotoriously lack debugging facilities, makingapplications that use IPC very difficult to debug.The problem is further exacerbated whenprocesses are distributed across a network in thequest to build scalable applications. In this case,effective debugging tools are a necessity, andtheir availability reduces development timesignificantly.

Talarian’s SmartSockets, a robust MOM productthat addresses many of the problems described inthis section, is the principal Talarian product.The rest of this booklet offers an introduction toSmartSockets.


SmartSockets®:An In-Depth LookTalarian’s SmartSockets is a robust, message-oriented middleware product that offers bothmessage queuing and publish-subscribecommunication models. SmartSockets enablesprograms to communicate quickly, reliably, andsecurely across LANs, WANs, and the Internet.SmartSockets manages network interfaces,guarantees delivery of messages, handlescommunication protocols, and deals with recoveryafter system/network problems. This lets softwaredevelopers use their skills to handle higher levelrequirements, rather than to solve the underlyingcomplexities of the network.

SmartSockets greatly reduces risk in softwareprojects where multiple programs mustcommunicate with one another. It speedsdevelopment and ensures portability andinteroperability. SmartSockets can be used in abroad range of technical applications includingreal-time command and control, high-performancemessage passing, high availability solutions, andmulti-tier client/server applications. SmartSockets'programming model is built specifically to offerhigh-speed interprocess communication,scalability, reliability, and fault tolerance.

The following components make up theSmartSockets product:

1. Application Programming Interface—a C/C++callable library of functions for working withmessages, communicating between processes, andmonitoring distributed applications.

2. C++ Class Library—an object-oriented layer ontop of the standard SmartSockets services.

3. Java Class Library—a version of SmartSocketswritten natively in Java offering Java programmersaccess to the publish-subscribe features ofSmartSockets.

4. RTserver™ process(es)—a powerful messagerouter that allows applications to use a publish-subscribe communications model; processesregister interest in specific subjects, clients publish(send) messages to a subject, and all processes thatregistered for that subject receive the messages.

5. RTmonitor™ process(es)—a graphical point-andclick interface for monitoring, administering, anddebugging a distributed application; allowsdevelopers to use a visual interface for watchingthings such as IPC traffic and process information.

6. Ready-to-use message types—predefinedmessage types to get the application developergoing quickly. Custom message types can bedeveloped with ease.

7. Sample C, C++, and Java Programs—anextensive set of sample C, C++, and Java programsto get you off to a fast start.

8. Documentation—available on-line and in print, acomplete bound set of manuals that are filled withexamples. Included is an easy-to-read tutorial.

SmartSockets has several capabilities that makebuilding distributed applications easier, whilekeeping the system up and running. SmartSockets’programming model is built specifically to offerhigh-speed interprocess communication,scalability, reliability, and fault tolerance. Anapplication developed with SmartSockets canconsist of multiple programs working together in aheterogeneous network. The following paragraphsdescribe the key features of SmartSockets.

High-Speed InterprocessCommunicationSmartSockets supports very high-speed messagerouting and delivery throughout a network.SmartSockets provides access functions sodevelopers can quickly encode, decode, and copy


messages. SmartSockets will transparentlydetermine the shortest route between programsusing a shortest-path algorithm. In general, the rateat which information can be passed usingSmartSockets IPC is restricted only by thelimitations of the physical network.

Publish-Subscribe Services

SmartSockets uses a powerful publish-subscribecommunications model in which programssubscribe (register interest) to a subject. Programsalso publish (send) messages to the subject. Once asubject has been subscribed to by a client process,the client will receive any messages published tothat subject in the application. Subjects are definedby the application developer and can be thought ofas a logical message address, providing a virtualconnection between client processes. InSmartSockets, these can be specified hierarchically(for example, "/market/stock/NYSE") and can bepublished and subscribed to using wildcards.

In traditional network applications, when twoprograms must communicate with each other, theyneed very specific physical network addresses (forexample, in TCP/IP, a node name and portnumber). If a program wants to send a message tomany other programs, it first would need to knowthe physical network addresses, and then create andmaintain a connection to all those programs. Thisarchitecture does not scale well, as configuration iscomplicated and tedious. The SmartSocketspublish-subscribe communications model allows aprogram to simply send the message with a subjectas the destination property; then, SmartSocketstakes care of routing the message to all programsthat are subscribed to that subject.

Once an application developer has written a clientusing the SmartSockets API, multiple instances ofthat process can be deployed on the same machineor different machines in the same LAN, WAN oranywhere on the Internet

The API is the same regardless of where theprocesses reside. Applications therefore can bedeveloped on a single machine and then distributedover a network as needed, all without changing asingle line of source code.

Peer-to-Peer Communication

As well as supporting the publish-subscribe modelof message routing described earlier, SmartSocketsalso supports direct peer-to-peer communicationbetween two programs. This is useful inapplications where very high-speed communication

is required between exactly two programs and nointermediate hops are warranted.

Multicast

When one system needs to broadcast data to manyclients, it can choose one of two ways of doingthis. The first is to send the same message to eachclient. This approach is effective, but it consumes atremendous amount of bandwidth as the same datarepeatedly crosses the network. A more efficientmethod is to use multicast, which is an Internetstandard for broadcasts that allows for a moreoptimized distribution. With multicast, the messageis sent to specific servers that then distribute thedata to local clients. In this way, enterprisebandwidth is conserved. Historically, multicast hassuffered from reliability issues—not every intendedclient received the message. Recently, however, thereliable multicast protocol (RMP) was designedand implemented to solve this problem. Today,Talarian is one of the first companies to implementmulticast with RMP and have it support mission-critical delivery of packets while preserving thebandwidth savings.

Asynchronous Messaging

Rather than block a process waiting for a messageto be delivered or for a reply to come back,SmartSockets allows messages to be deliveredasynchronously without blocking the mainlinelogic of the calling program. Sending messagesasynchronously allows a program (and the entiredistributed application) to operate at higherperformance levels because the program cancontinue its tasks without waiting for a reply to amessage it has sent. Also, operating asynch-ronously allows the system to respond morequickly to external events.

With SmartSockets, it is simple to initiateconcurrent operations involving multiple networkplatforms and to have them run to completion inparallel. SmartSockets' asynchronous functionalityallows developers to leverage the inherentparallelism of the network environment.

Synchronous Messaging

Non-blocking RPCs are available withinSmartSockets. These RPCs allow a client processto wait for a specified period of time for a specificmessage. Other messages that arrive while waitingfor the RPC to return are buffered and processedonce the RPC completes or the time-out expires.


Thread Safe

SmartSockets is completely thread safe, allowingmultiple threads to operate simultaneously on asingle connection. In multiprocessor environmentswith operating system kernel thread support,multiple threads can greatly increase performance.

Benefits: Increased scalability, increasedproductivity, reduced risk, and more productiveuse of resources.

High Availability andReliabilityIn many mission-critical applications, faulttolerance and reliability are importantrequirements. The systems require continuousoperation—24 hours a day, 7 days a week—regardless of hardware or software failures.SmartSockets achieves increased reliability in itscommunication layer by transparently checking forproblems that occur when processes are connectingand sending or receiving messages.

SmartSockets IPC has been designed to handlemany different kinds of network failures. Ingeneral, the SmartSockets IPC avoids operationsthat can block (or stall) indefinitely, or puts anupper limit on the amount of time these operationscan block, and it periodically checks for potentialfailure conditions.

Publish-subscribe services are enabled through aSmartSockets program called RTserver. RTserveris a high-speed software message router with whichprograms can connect to send/receive messages toother programs in the application group. AnRTserver may or may not reside on the samemachine as the programs that connect to it.

SmartSockets allows programmers to achieve ahigher level of availability in a distributedapplication through the use of softwareredundancy. Redundancy involves one or morebackup (but active) processes for each primaryprocess. For example, to ensure that a specifiedprocess continues to run regardless of problemsthat may occur in the network, one or more backupprocesses can be run. Backup processes can bereceiving the same data as the primary process allalong and be ready to take over instantly if theprimary process fails.

Quality of Service

To meet the system and network outage recoveryrequirements, SmartSockets allows the sendingprogram to optionally specify guaranteed messagedelivery on the messages it sends out. If an outageshould occur to the sending program before amessage is delivered, the message is automaticallyrecovered and delivered to the receivingapplication when the system is brought back up.SmartSockets also handles the complex one-to-many case where a message must be guaranteed tomultiple receivers.

By using guaranteed message delivery, distributedapplications that require high availability can beintegrated easily. This simple concept—which isexceedingly difficult to program—allows messagesto be reliably delivered between programs in anapplication, eliminating the need for complexerror-recovery code to be written into distributedapplications and providing a much more timelymechanism than batch file transfer.

Dynamic Message Routing

SmartSockets handles changes and failures to thenetwork through dynamic message routing.Routing tables in the RTservers are updated in realtime as changes occur in the network (such asprocesses or machines going down). Messages arealways sent through the RTserver virtual networkusing a shortest-path algorithm. This enables adistributed application to continue to function evenin the face of component failures.

The popular message queuing products cannothandle changes to the network easily. In general,they are preconfigured to forward messages from aqueue to another queue. If any component fails inthis path, the message queuing software is stuckuntil the failed component is functioning correctly.

Multiple RTserver™ Processes

Because of SmartSockets’ modular architecture, adistributed application can be built with anynumber of RTservers, with multiple protocolssupported by each. A simple application may useonly one RTserver to provide all services. A morecomplex application may use multiple RTservers toreduce network bandwidth and to add performance,load sharing, modularity, and reliability. Usingmultiple RTservers reduces network traffic and thenumber of direct links that must be maintained.

Benefits: Increased application availability,operation 24 hours a day, 7 days a week.


Distributed ApplicationMonitoring, Administration,and DebuggingDebugging and monitoring a distributedapplication is extremely difficult because of themany variables involved (network, machines,programs) and the primitive tools that are offeredby the operating systems. SmartSockets offers bothgraphical and programming tools to make themonitoring, administration, and debugging ofdistributed applications much easier. Compre-hensive information can be gathered in real timeabout all facets of a running SmartSockets project,including message traffic, message buffering,memory usage, and CPU usage. It is possible toquery each client for the subjects it has subscribedto, the options that have been set for it, the node itis running on, and the architecture of that node.Monitoring can be done interactively through thegraphical user interface or programmaticallythrough the programming interface.

Graphical Interface

RTmonitor is a graphical tool designed to monitor,debug, administer, and test an entire SmartSocketsapplication. RTmonitor provides the capability topublish messages and to monitor critical IPCinformation in real time as it changes, all withouthaving to make a single change to the applicationand without incurring performance overhead in theapplication when monitoring is not in use. TheRTmonitor GUI is a multi-window developmentinterface that provides snapshots and continuousreal-time views of the activities occurring within aprocess IPC environment.

The ability to monitor a network applicationexecuting, with all its IPC activities visible, isinvaluable when tracking down elusive problems.The total development time can be cut significantlythrough the use of RTmonitor alone. SmartSockets’debugging and monitoring capabilities are valuablesupport tools as well. Applications built withSmartSockets even can be monitored in production.No longer is it necessary to recreate problems orspecial debug versions of an application to studyproblems. With RTmonitor, there is no need to askcustomers to submit large log files. SmartSocketsapplications can be studied wherever they are—assoon as they display irregular behavior.

Monitoring Interface

A subset of the SmartSockets robust monitoringAPI was used to build the RTmonitor graphicalinterface. From within their program, developerscan use the monitoring API to track more than 300different variables and events. This API providesmechanisms to track when processes start andwhen they fail, when they subscribe/unsubscribe toa subject, or when a specific message type ispublished or received. Actions can be taken by aprogram when a process joins an application orwhen it terminates.

When a program is linked with the SmartSocketslibraries, it is automatically instrumented formonitoring. Calls to the API or clicking on choicesin RTmonitor turn it on. By embedding monitoringwithin the SmartSockets API, developers takeadvantage of varied information such as CPUusage, memory usage and message queue sizes.

Monitoring can be done either synchronously(polling) or asynchronously (watching). Whenpolling is used, a call is made to the API to collectthe specified information and the function does notreturn until the operation is complete. Whenwatching is used, a call is made to the API toregister interest in specified variables or events.The function returns immediately. Whenever thespecified event happens, a monitoring message issent asynchronously to the program. Typically, theprogram will use callbacks to process theinformation. Both polling and watching can beused within the same program.

Southwest Airlines Flies withSmartSockets.In late 2000, Southwest Airlines, the fourth-largestdomestic airline in the U.S., deployed TalarianSmartSockets as the real-time infrastructure for itsSWIFT (Southwest Integrated Flight-Tracking)system. SWIFT provides flight managers with areal-time status report on flight tracking and fuelusage, passenger loads, crew management data,gate information and weather reports for more than2,600 daily flights. Says Phil Hyatt, technicalproject lead for Southwest Airlines, “We needed asystem that could be built quickly and couldintegrate smoothly with SWIFT’s publish-and-subscribe architecture in which information isdelivered instantly to the correct parties as itchanges. What really appealed to us wasSmartSockets’ complete and easily configurableAPI. Its simplicity and flexibility allowed us toimplement the project in less than a month.”


Message Logging

SmartSockets messages can be loggedautomatically to a file at any point along the way:

1. Messages arriving for a program2. Messages leaving a program3. Messages arriving at an RTserver4. Messages leaving an RTserver

Messages can be logged in ASCII or binary format.ASCII log files can be edited or moved easily fromone platform to another. Binary message logging ismuch faster and uses less disk space.

Message types can be assigned to various loggingcategories (classes). Logging for a specific classcan be dynamically turned on and off as theprograms are running.

Message logging allows the developer (or end user)to view the messages sent or received by anyprocess. A developer also can use these messagefiles to set up a controlled test environment inwhich to test the behavior of a process. This isdone by having the process receive its input fromthe message file instead of from the otherprocesses.

Benefits: Reduced maintenance costs andincreased productivity.

Platform and ProtocolIndependenceApplications built with SmartSockets areguaranteed to be portable across differentplatforms. For example, an entire application orparts of an application can be moved easily from aPC running Windows NT to a Sun SPARCstation.Because SmartSockets offers a portable C API andC++ and Java classes, source code is immediatelyportable across different platforms. The IPCportion of a distributed application—often the mostplatform dependent—need be written only once.

Automatic Data Translation

SmartSockets allows messages to be sent betweenprograms on different types of computers (forexample, Intel PCs and Sun SPARC). When amessage is sent through a connection, the integers,real numbers, strings, and other primitive datatypes within the message are convertedautomatically from the formats of the sendingprogram to the formats of the receiving program;no action is required by the application developer.

No unnecessary data conversions are performed ifthe sending and receiving programs are running oncomputers with compatible data types (forexample, Sun SPARC and HP PA-RISC).

With SmartSockets’ cross-platform and multi-protocol support, developers can distributeprocesses anywhere over heterogeneous networksand share processing power. Programmers canmodify network components and move resourcesand programs from one location to another withcomplete transparency. With SmartSockets ITmanagers can choose the best computing solutionfor a particular need.

Platform Support

SmartSockets is supported on numerous computingplatforms, including the operating systems:

1. Unix (including Solaris, HP-UX, AIX,DEC Unix, Compaq True64, and IRIX)

2. Windows NT and Windows 20003. VxWorks4. IBM OS/3905. Linux

Client platforms include all the above as well asWindows 95/98/ME, Macintosh, and Java clients.

This list is updated frequently. Please contact yourlocal SmartSockets sales representative for an up-to-date list.

Protocol Driver

One benefit of SmartSockets is that it shields thedeveloper from having to understand underlyingnetwork protocols. Although SmartSocketssupports most of the popular protocols, theSmartSockets Protocol Driver enables customers toadd additional protocols (such as proprietary ones)easily.

Benefits: Protected investment in hardware andsoftware.

Powerful Message HandlingPrograms built with SmartSockets communicatevia messages. Messages consist of a header and adata part, which holds the information beingtransferred and is dependent on the message type.The message header contains properties thatdescribe the message, such as destination (subject),message type, priority, level of guarantee, read-only, and other information.


Automatic Message Buffering and FlowControl

Distributed applications typically require a methodto establish data-flow between the client processes.A single program often will need to read messagesfrom many different programs. In a SmartSocketsapplication, each program has message queues thattransparently buffer the messages when there arevariable traffic rates, providing automatic flowcontrol. This method of communication increasesperformance and greatly simplifies development.

Prioritized Message Queues

All messages in SmartSockets may have a priorityattached to them. When a message is delivered to aclient process, it is added to the client’s messagequeue in priority order (higher priority messagescome before lower priority messages). This forceshigher priority messages to be processed beforelower priority messages sent at an earlier time.

SmartSockets’ message queues support messageprioritization, searching, and selection. Messagescan be retrieved based on FIFO, LIFO, and othertypes of priority specifications. Byte streams,RPCs, shared memory, and sockets are, bycomparison, primarily FIFO mechanisms.

Reusable and Extensible Message Types

SmartSockets provides more than 150 standardmessage types that are used by SmartSocketsinternally and are available to the developer. Whena standard message type does not satisfy a specificneed, the developer can create a user-definedmessage type. (This requires only a single APIcall.) Both standard and user-defined messagetypes are handled in the same manner. Once themessage type is created, messages can beconstructed, sent, received, processed, and loggedthrough a variety of methods.

Load Balancing

SmartSockets-enabled programs and RTservers cansubscribe and unsubscribe as needed by the givenapplication requirements. Dynamic load balancingis designed into SmartSockets using selectedalgorithms including “least busy” and “roundrobin.” Message delivery can be controlled via asimple round robin or by forwarding messages tothe process that is least busy, where “least busy” isdefined as the process that has the fewest numberof messages unprocessed.

Benefits: Increased performance and reliability.

ScalabilitySmartSockets was designed to scale to handlethousands of concurrent users (or processes).Scalability comes from a variety of differentfeatures, which are summarized here:

1. SmartSockets has a hierarchicalnamespace. This means subject names,which are used for a variety of purposesincluding application partitioning, can bespecified hierarchically (for example,“/company/technology/software/talarian”or “/company/transport/auto/ford”), muchlike many of the popular file systems.

2. The SmartSockets namespace can bearranged hierarchically into any numberof levels. (Other middleware productshave no namespace, a flat namespace, or alimited number of levels). In largeenterprise-wide applications, developerswill need to use many levels of thehierarchy to properly partition thenamespace.

3. SmartSockets does not require a routingprocess, or daemon, on every machinewhere a client process is running. (Otherproducts require at least one routingprocess on every machine. Some productsrequire multiple processes on eachmachine. This is not reasonable whendeploying to many machines.)

4. Messages are routed dynamically inSmartSockets. Therefore, information sentfrom one application to another couldpotentially take a different path every timeif parts of the network becomeunavailable. Message routing can beconfigured in two ways: manually orusing default routing

5. Default routing is calculated using anOSPF (Open Shortest Path First)algorithm that corrects all the problems ofthe older RIP (Routing InformationProtocol) algorithm, which is based onhop counts. Messaging middleware usingRIP takes a long time to stabilize when achange occurs (for example, if a machineor process goes down) because hop countsmust be propagated throughout. Defaultrouting in SmartSockets uses the fewestnumber of RTservers possible. When


changes occur in the network, thesechanges do not need to be rippled all theway through SmartSockets.

6. SmartSockets-enabled processes can fail-over to new RTserver processes runningon any machine should the one they arecurrently connected to fail for any reason.

7. SmartSockets-enabled programs can beset up to connect to any one of a randomset of RTservers across a network. Thisprevents an RTserver from beingoverloaded with a large number ofprograms connecting to it.

8. There is no single place in a SmartSocketsserver cloud that has all the informationneeded to resolve routes. In this way,SmartSockets works much like theInternet and DNS. Information aboutrouting and the locations of processes iskept in a “virtual distributed real-timedatabase” in the SmartSockets network ofprocesses.

9. SmartSockets’ RTservers and programsdo not require “root” or “system”privilege to install or run. Most othermessaging products require specialprivileges to install or run. In general, thisis not realistic when deploying tothousands of machines. In the case ofMQSeries from IBM, changes must bemade to the operating system kernel onmost supported platforms.

10. SmartSockets messages can be publishedto a particular subject in the namespace orcan be published to a subject withwildcards in it (for example, “/company-/transportation/*”).

11. SmartSockets programs can subscribe to aspecific subject, multiple subjects, ormultiple subjects using a wildcard.

12. All SmartSockets RTserver processes donot need to be connected to one another.SmartSockets will dynamicallyreconfigure and update its routing tablesas RTservers come and go.

13. SmartSockets can perform contextbridging, translating messages from oneprotocol to another as message routingoccurs. For example, a message could besent down one connection via TCP/IP andthen be delivered to the receiver via SNA.This facility includes additional protocolsthat might be added by the customer.

14. SmartSockets uses a “just-in-time,receiver makes right” approach in order totranslate the message into the properformat. Even if a message goes throughseveral hops, only the final receiver doesthe translation and the translation is notdone until the receiver is ready to "use"the message. SmartSockets provides alldata translation transparently: EBCDIC-ASCII, big endian–little endian, floating-point numbers, and the like.

15. SmartSockets includes graphicaldevelopment tools that allow you tovisualize your entire project and itstopology. Further, the application can bemonitored in real time to watch messagetraffic and quickly pinpoint anybottlenecks.

Benefits: Maximum use of existing computerresources and virtually unlimited expansioncapability.

SmartSockets at Credit Suisse First Boston. In late 1999, Credit Suisse First Boston(CSFB), one of the world’s largest securities-trading firms, adopted SmartSockets as the real-timeinfrastructure for its high-speed messaging system that links 4,000 equities traders around theglobe. SmartSockets powers the Global Application Intercommunication Architecture at CSFB,enabling high-speed messaging among regional offices spread across 30 countries on sixcontinents using more than 500 applications. Says Raymond Mulligan, vice president of EquityTechnology at CSFB, “SmartSockets allows us to implement publish-subscribe messaging withouthaving to build an elaborate broadcast infrastructure around it. With clients distributed around theglobe, it would be impossible to install ancillary hardware for them all. With SmartSockets, thatproblem was eliminated.”


Benefits ofSmartSocketsBuilding distributed applications can be a verycomplex and risky venture. For such difficultproblems, SmartSockets offers maximum power andflexibility together with superior ease of use. TheSmartSockets programming model has severalimportant benefits that are outlined in the sectionsthat follow.

Increased ProductivityThe easy-to-understand multiprocess programmingmodel of SmartSockets eliminates the need fornetwork programming skills. A single call to aSmartSockets function is the equivalent of many linesof complex network programming. As a result, thecost of developing a distributed application issignificantly reduced.

Reduced RiskSmartSockets has been used and tested as part ofmission-critical systems for years across a variety ofindustries including financial, telecommunications,process and manufacturing, and aerospace. This trackrecord means proven reliability and reduced risk.

Increased ScalabilityAs an application grows in terms of the number ofprocesses involved, the amount or rate of messagetraffic, and the number of machines involved,SmartSockets can grow with it. Because both theclient and server processes can be distributed across anetwork within the SmartSockets programmingmodel, the application can make maximum use ofexisting computer resources while offering virtuallyunlimited expansion capability. Applications can bebuilt on a single machine and then deployed over anetwork without changing even a single line ofsource code.

Protected Investment inHardware and SoftwareSmartSockets allows IT shops to keep theinvestment in software that they have alreadydeveloped. By adding calls to the SmartSocketsAPI within already existing software, developerscan quickly and easily integrate legacy programsinto the distributed application.

Because of SmartSockets' multiplatform support,IT managers will be able to make use of theirexisting hardware. In addition, if you wish tochange hardware vendors, your SmartSocketsapplication will be usable on the new platform.SmartSockets does not require kernelmodifications or any other changes to be made tothe computer.

Reduced Maintenance CostSmartSockets reduces software maintenancecosts by virtually eliminating the need fornetwork programming skills. SmartSocketsallows a software engineer to write distributedapplications without going through the tediousand expensive process of writing low levelnetwork software. Furthermore, as updates to theoperating system occur, SmartSockets is alsoupdated to mask those operating system changesfrom the user. Finally, moving all or part of anapplication to another platform can be donetransparently with SmartSockets.

Increased ApplicationAvailabilitySmartSockets offers several capabilities thatgreatly increase the availability of a distributedapplication. SmartSockets offers easilyconfigurable options for responding to networkfailures, hot failover to parallel processes when aprocess or machine goes down, guaranteed


message delivery, error callbacks when an exceptionoccurs, and sophisticated real-time monitoring toolsto keep an eye on what is happening. All thesesophisticated features allow developers to buildapplications that are robust and reliable.

More Productive Use ofResourcesSmartSockets means computers spend less timewaiting and more time working. It also gives ITmanagers the flexibility to match the technology tothe business need. For example, a shop may havespecific message types that cause control action to betaken by the SmartSockets client processes. Messagesassociated with other less critical needs can be sentand added to the queue, to be worked on after thehigher priority messages have been processed.


Getting Started withSmartSocketsYou can get started with SmartSockets by simplyusing the API (a C library, C++ class library, or JavaJAR file) in the parts of your C/C++ or Javaprograms that need to communicate with otherprograms in your network. You can also replace thecommunication sections of your existing programsfor a more rapid implementation and faster return oninvestment. Or, like many SmartSockets customers,you may decide the benefits are too good to bepostponed and redesign your existing application toincorporate this exciting new technology.

Example C ProgramsTo demonstrate how easy SmartSockets is to use,this section contains two heavily commented Cprograms. The first program simply publishes amessage to a subject (it requires only two lines ofactual code). The second program subscribes tothe subjects, reads the message, and prints out itscontents (it is only five lines of code).Note that all SmartSockets API calls start with"T"(for Talarian).

/* Program 1: send.c */

#include <rtworks/ipc.h>

int main( int argc, char **argv){

/* This one function call will perform the following tasks:

1. Since there was no explicit call to connect to RTserver, theprocess will first establish a connection to RTserver (thismight including auto-starting RTserver if it is not alreadyrunning).

2. A message of type INFO will be created.

3. The data part of the message will contain the text string"Hello World".

4. The message will be sent to the RTserver process to bedelivered to the subject "/ss/tutorial/lesson 1"; any processthat has subscribed to this subject will receive the message.

5. The message will then be destroyed. */

TipcSrvMsgWrite("/ss/tutorial/lesson1",TipcMtLookupByNum(T_MT_INFO), TRUE, T_IPC_FT_STR,"Hello World!", NULL);

TipcSrvFlush(); /* ensures message is sent immediately */}


/* Program 2: receive.c */

#include <rtworks/ipc.h>int main(argc, argv)int argc; char **argv;{

T_IPC_MSG msg; T_STR MsgText;

/* The following function call performs two tasks:

1. Since there was no explicit call to connect to RTserver,the

process will first establish a connection to RTserver (thismight include auto-starting RTserver if it is not alreadyrunning).

2. Inform RTserver to forward any message which has been sent to the subject "ss/tutorial/lesson1" by any client in the application. */

TipcSrvSubjectSetSubscribe("ss/tutorial/lesson 1", TRUE);

/* This function calls gets the next message from its messagequeue; The T_TIMEOUT_FOREVER constant specifies that the functionwill block (wait) forever for a message. You can specify anactual time-out period for this argument; for example, 10.0 wouldmean the function would return with a failure code after 10seconds. */

msg = TipcSrvMsgNext(T_TIMEOUT_FOREVER);

/* We now have a message to work with.The following call sets the messagepointer (i.e., the current field) tothe first field in the data partof the message. */

TipcMsgSetCurrent(msg, 0);

/* The next call gets the string fromthe data part of the message.*/

TipcMsgNextStr(msg, &MsgText);

/* Finally, print out information retrieved from the message. */

TutOut("Message Text = %s\n", MsgText);

}

Could network programming this easy help your business? Find out more about Talarian SmartSockets athttp://www.talarian.com. You may also contact us by e-mail at [email protected], or call toll-free,(800) 883-8050.

© 2000 Talarian Corporation. All Rights Reserved. Talarian, “The world works in real-time,” SmartSockets, RTserver and RTmonitor aretrademarks of Talarian Corporation that may be registered or pending in certain jurisdictions. Other product names may be trademarks oftheir respective companies. WPMW 1001 1000

TALARIAN CORPORATE HEADQUARTERS333 Distel CircleLos Altos, CA 94022-1404(800) 883-8050FAX (800) 883-8057

TALARIAN LIMITED68 Lombard StreetLondon EC3V 9LJ+44 (0) 20 7868 1630FAX +44 (0) 20 7868 1752

E-Mail [email protected]

talarian : everything you need to know about middleware

Documents