Difference between revisions of "GeometryServiceNetworkProtocol"

From BRL-CAD
(Rename title for clarity)
(Enter more of the libPKG header use description.)
Line 58: Line 58:
  
 
====libPKG Part====
 
====libPKG Part====
Due to some C and C++ incompatabilities, the libPKG "Type" parameter is used as "Magic2" in the GSNet Protocol.  NetMsg routing is performed on the "GS Msg Type" parameter
+
Due to some C and C++ incompatibilities, the libPKG "Type" parameter is used as "Magic2" in the GSNet Protocol.  To address this change, NetMsg routing should be performed on the "GS Msg Type" parameter rather than the "libPKG Type" parameter.
 +
<br /><br />
 +
Table showing modifications described above:
 +
<br /><br />
 +
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #666699; padding: 0;"
 +
|style="border: 1px solid #666699; background-color: #666699; color: #FFFFFF; width: 180px;"|'''libPKG element'''
 +
|style="border: 1px solid #666699; background-color: #666699; color: #FFFFFF; width: 180px;"|'''GSNet element'''
 +
|-
 +
|style="border: 1px solid #666699;"|Magic
 +
|style="border: 1px solid #666699;"|Magic01
 +
|-
 +
|style="border: 1px solid #666699;"|Type
 +
|style="border: 1px solid #666699;"|Magic02
 +
|-
 +
|style="border: 1px solid #666699;"|Length
 +
|style="border: 1px solid #666699;"|Length
 +
|}
 +
 
  
 
====GSNet Part====
 
====GSNet Part====

Revision as of 08:07, 24 January 2011


GSNet
The Geometry Service Network (GSNet) Protocol is a TCP/IP based protocol designed to facilitate socketed communications between Geometry Service Nodes on a network. A Geometry Service Node is defined as any softwares that supports communication via the GSNet Protocol.



GSNet Msg (Visual) Breakdown

GSNetMsgBreakdown.png


GSNet Msg

Header

The header of the GSNet Msg contains the information necessary for quickly determining authenticity, type and length. Geometry Service's network library, libNetwork, is built upon BRL-CAD's networking library: libPKG. This causes the header byte layout to look like this:

Element Length Value
Magic1 int16 (2 Bytes) Always 0x41FE
Magic2 int16 (2 Bytes) Always 0x5309
MessageLength int32 (4 bytes)
MsgType int16 (2 bytes)
MessageUUID String (Variable bytes)
HasRegardingUUID Boolean (1 byte)
RegardingMessageUUID String (Variable bytes)


libPKG Part

Due to some C and C++ incompatibilities, the libPKG "Type" parameter is used as "Magic2" in the GSNet Protocol. To address this change, NetMsg routing should be performed on the "GS Msg Type" parameter rather than the "libPKG Type" parameter.

Table showing modifications described above:

libPKG element GSNet element
Magic Magic01
Type Magic02
Length Length


GSNet Part


Data



List of NetMsgTypes.

List of Common NetMsg Exchanges