NSIS-ka
A free C++ implementation of NSIS protocols

Opened 10 years ago

Last modified 10 years ago

#86 new enhancement

Support for sending Data PDU in Q-Mode (stateless D-mode)

Reported by: bless Owned by: bless
Priority: minor Milestone: Release 0.97
Component: GIST Version:
Keywords: Cc:

Description (last modified by bless)

5.3.2.  Q-mode Encapsulation

   Q-mode encapsulation MUST be used for messages where no routing state
   is available or where the routing state is being refreshed, in
   particular for Query messages.  Q-mode can also be used when
   requested by local policy.  Q-mode encapsulation is similar to normal

and Table in sec. 5.5 says:

   +----------+---------------+-------------------------+--------------+
   |  Message | Normal D-mode |  Query D-mode (Q-mode)  |    C-mode    |
   +----------+---------------+-------------------------+--------------+
   |   Data   |   If routing  |  If the MRI can be used |     If a     |
   |          |  state exists |   to derive the Q-mode  |   messaging  |
   |          |  for the flow |    encapsulation, and   |  association |
   |          |     but no    | either no routing state |    exists    |
   |          |   messaging   |  exists or local policy |              |
   |          |  association  |     requires Q-mode     |              |
   +----------+---------------+-------------------------+--------------+
   Transfer-Attributes:  Attributes defining how the message should be
      handled (see Section 4.1.2).  The following attributes can be
      considered:

      Reliability:  Values 'unreliable' or 'reliable'.

      Security:  This attribute allows the NSLP to specify what level of
         security protection is requested for the message (such as
         'integrity' or 'confidentiality'), and can also be used to
         specify what authenticated signalling source and destination
         identities should be used to send the message.  The
         possibilities can be learned by the signalling application from
         prior MessageStatus or RecvMessage notifications.  If an NSLP-
         Message-Handle is provided, GIST will inform the signalling
         application of what values it has actually chosen for this
         attribute via a MessageStatus callback.  This might take place
         either synchronously (where GIST is selecting from available
         messaging associations), or asynchronously (when a new
         messaging association needs to be created).

      Local Processing:  This attribute contains hints from the
         signalling application about what local policy should be
         applied to the message; in particular, its transmission
         priority relative to other messages, or whether GIST should
         attempt to set up or maintain forward routing state.

So we should use local processing hints for this...

Change History (1)

comment:1 Changed 10 years ago by bless

  • Description modified (diff)
Note: See TracTickets for help on using tickets.