Connection Management Layer
TCP/IP
Fig.1.OverallArchitectureofComms/CPN.
Thedesignofall threelayershasbeenbasedon vefunctionalrequirementsrepresenting
theservicesexpectedofthelibrary.TheyarethatComms/CPNshallprovidemeansforCPN
modelsto open connections to externalprocesses,accept incomingconnectionsrequested by
externalprocesses,senddatato externalprocesses,receive datafromexternalprocesses,and
close connectionsto externalprocesses. Comms/CPN hasbeendesigned asan SML library
toreectthenon-functionalrequirementsofallowingeasyintegrationwiththeDesign/CPN
tool,and sothatthecommunicationfacilitiesareseparatefromtheDesign/CPNGUI.This
allowsthecommunicationfacilitiestobeaccessedusinglibraryfunctionsthatcanbeincluded
in code segments of transitions, auxiliary boxes, or in the top loop of the Design/CPN
simulator.
sues wereidentied.ThesearetheFundamental Methodof Communication,Connections and
Connection Management,and Data Transfer.The designand requirementsreectadesireto
make Comms/CPN applicableto thewidestrange of applicationspossible.In thefollowing
subsections wediscusseach of these designissuesindetail.
2.1 Fundamental Method of Communication
The design decision was made for the underlying communication protocol to be TCP/IP.
This comes from the requirement that data transmissions must be error free and in-order,
and TCP/IP is a transport protocol that achieves this. TCP/IP is also desirable as it is
a standard protocol, and most devices implement a TCP/IP stack and most programming
environments(includingSML)provideaninterfaceto itthroughTCP/IPsockets.
Masterthesis [19] examined theuse of TCP/IP to communicatebetween Design/CPN
and externalprocesses. It summarisedthe ideasand concepts from variouspapers and
pub-lications. Ofparticularimportancewas[14], focussingon interactionbetweenDesign/CPN
and Java processes. Two solutionswerepresented in[19] asto how TCP/IPcommunication
betweenDesign/CPNandexternalprocessescouldberealised.TherstwascalledthePure
TCPSolutioninwhichDesign/CPNconnecteddirectlytoexternalapplicationsviaTCP/IP
using functions in a communication library. The second was called the Messenger Solution
in whichlibraryfunctions were usedto communicate(via Unixpipes)withan external
mes-senger subprocess written inJava.The Java subprocess then used TCP/IP to communicate
with externalprocesses.
Both thePure TCP and Messenger solutions would provideusable communication
facil-ities. The fundamental design choice for Comms/CPN was made to choose the Pure TCP
solution for the design of Comms/CPN. Pure TCP provides for easier and tighter
integra-tion with Design/CPN, and can be used wherever Design/CPN is used. The Messenger
solution (following the suggested implementationin [19]) does not provide foreasy or tight
integration because it uses a programming language other than SML. The Communication
Layerreectsthisdecision.ThislayerprovidesaninterfacetoTCP/IPfortheComms/CPN
library.TheprimitivesprovidedinthislayerareusedbytheConnectionManagement Layer
to establishTCP/IP connectionsto externalprocesses, sendand receive datain theform of
streamsofbytes,and tocloseTCP/IPconnectionstoexternalprocesses.Moreover, itis
pos-sible to implementan architecturesimilarto thetheMessenger solutionof [19]based purely
on Comms/CPN.
2.2 Connections and Connection Management
A connection represents a communication channel between a CPN model and an external
process. It is the Connection Management Layer that manages connections between CPN
models and external processes by creating, storing, and removing connection information.
Nonfunctionalrequirementsofthelibrarystatethatthelibrarymustbecapableofhandling
multipleconnections, and thatthese connectionscan be establisheddynamicallyduringthe
simulationofa CPNmodel.Also,requirementsstate thatthelibrarymustprovidea
mecha-nism foridentifyingconnections andabstracting fromlowlevel socketidentiers.Thedesign
of theConnection Management Layerreects these requirements.
ConnectionManagement Layeris to assigna uniquestring to each connectionasit ismade.
Stringidentiersoer theadvantageofbeingmore human-readableandrecognisablethanan
integer or a low level socket identier. A string can be provided by the user (to further aid
in recognisability) oritcould beprovidedinternally byComms/CPN. Strings can easilybe
used as tokens withina CPN modelto pass connection identiers around duringsimulation
of theCPN model.
Connection Attributes. When a connection is created, it is necessary for information about
this connection to berecorded. Theseconnection attributes must allowthe connection to be
identiedand used. In order to identifytheconnection, the uniquestring identiermust be
stored, and in order to use the connection, the low level TCP/IP socket identier must be
stored.TheuniquestringidentierallowsconnectionstobeidentiedwithinCPNmodels,and
the lowlevel TCP/IPsocket isneeded inorder to send and receive data. Without recording
these twopieces ofinformation, theestablishmentof connectionsbecomesuselessasthere is
no way to identifythem or to use them. Beforea connection is established, a check is made
to ensurethatthegivenuniquestringidentierisinfactunique.Ifnot,theconnection isnot
established. Multiple connections can be open simultaneously,soa data structure is needed
to storetheconnectionattributesofmorethanoneconnection.TheConnectionManagement
Layercontainsamechanismto dothis,calledtheConnection Storage Mechanism,andadata
structure inwhich theattributesare stored.The datastructuremustallownew information
to be stored, existinginformationto beretrieved, and oldinformationto be removed.
2.3 Data Transfer
AnonfunctionalrequirementofComms/CPNisthatthelibrarymusthavethecapabilityto
sendandreceivealltypesofdata,includinguserdenedtypes(coloursets).Thisisimportant
in increasingthe overallusefulness ofComms/CPN. TCP/IP dictates that datamust bein
the form of a sequence of bytes for transmissionacross a network, so data objects must be
converted into thisformfor transmission.
TheMessagingLayerofComms/CPNwithintheConnectionManagementLayerprovides
a solution. Generic send and receive functions that send and receive sequences of bytes,
regardless of the type of the data objects being transmitted, can be written and included
in the Connection Management Layer. This provides a way for users to send and receive
sequences ofbyteswithouthavingtheresponsibilityof implementingtheactualsending and
receiving functions themselves.
Inordertoconvertdataobjects toandfromsequencesofbytes,encodinganddecodingis
necessary.An encoding functionconverts a dataobject into a formsuitable fortransmission
via TCP/IP,and a decodingfunction converts a sequence of bytesinto a data object. SML,
being a functional programming language, allows functions to be passed as parameters. In
thisway,encodingand decodingfunctionscan bewrittenforanydatatype desired,and can
then be passed as parameters to the generic send and receive functions. The generic send
function appliesthe encoding function to a data object in order to convert it to a suitable
form fortransmission.Similarly,thegenericreceivefunctionappliesthedecodingfunctionto
a received sequence of bytes to form data objects. Inthis way,any type of datacan be sent
or received,providedthe corresponding encoding and decodingfunctions have been written.
Encodinganddecodingfunctionsforcommonlyuseddatatypesaresuppliedwiththelibrary,
e.g. forstringsand integers.
sistent format regardless of its type. The virtual byte stream service provided by TCP/IP
allowsforthe transmissionand receptionof sequencesof bytes. However, when dealingwith
many dierent types of data (including user dened types) this is not always adequate. A
morestructuredapproach isrequiredtodelineateitems ofdatafrom thevirtualbyte stream
to provideabetter servicethanjustastreamofbytes.Dataneedsto bepacketised for
trans-mission sothat when an item of data is sent, the receiver knows when all of it hasarrived.
The solutiontoachieve thisatomicityisto segment thestreamofbytes,and to provideeach
segmentwithaheaderthatdescribesit.Asegmentofbytes(payload)togetherwithitsheader
make up adata packet. A message isone ormore of these packets.
ThepacketformatchosenforComms/CPNconsistsofaonebyteheaderandamaximum
of 127bytesofpayloaddata.ThisisillustratedinFigure2.Seven bitsoftheheader indicate
the length of the payload data attached to it (i.e. 2 7
1 = 127 bytes) and the remaining
bit indicateswhether thisis thelastpacket inthetransmissionof thedataitem, in thecase
where a data itemis greater than 127 bitsin length. Inthis way,the header allows variable
length data packets to be handled. It must be stressed that the maximum of 127 bytes of
payload datacan easilybechanged by choosing adierent sized header.What is important
is that the peer entity in the external process (with which communication is taking place)
implementsthe same protocol at theMessaging Layer.
The choice of a one-byteheader is somewhat arbitrary,asthere doesnotappear to have
been any studies conducted regarding ideal packet length when transferring data between
Design/CPN and external processes. It should be mentioned that other segmentation and
assemblyprotocols could beused to achieve thesame service.