Re: Message-id and Session-id

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I believe that saying that session and message IDs are not too
useful is a little bit of a simplication and not thinking ahead.

First, the message ID is a great piece of info to be used
for correlation. That is, if it is saved and provided to
lower levels, then if an event occurs, then the ID can
be sent with the event report for correlation.

Secondly, when the transport is connectionless, a message
ID can be used to determine duplicates and lost messages.

Thirdly (this is what Wes covered, but did not fully explain)
is that a "client" (manager) application may submit multiple
requests and the "server" (managed system), may perform them
concurrently, and a later request may be completed before
and earlier request. The message ID is what is used to pair
a response with a request.

Of course if messages can only be sent over a connection
oriented transport, and requests are always processed
in order, then there are not too much benefit other
than correlation.

On Wed, 24 Nov 2004, Wes Hardaker wrote:

> >>>>> On Wed, 24 Nov 2004 13:39:19 +0800, "Íõº±" <y030737@njupt.edu.cn> said:
> 
> y030737> 1. when does the message-id increasing? 
> 
> It is entirely up to the client application.  It can reuse the same
> message id if it wants (and hopeful do so and not get confused).  The
> server doesn't care what the message ID is.  It merely puts it in the
> reply RFC to help the client recognize what the response is responding
> to.
> 
> y030737> 2. how does the session-id create?
> 
> The server creates that and hands it to the client during start up.  I
> think this may not be complete in -04???  But will be in -05.
>   
> y030737> In followed example, (in 7.5), the first message acquired a
> y030737> lock successfully, I supposed the message is identified by
> y030737> "101" , and the message is part of the session 150 of
> y030737> clientA.  then clientB try to acquire a lock through message
> y030737> "101" in its session 454, of course failed.
>   
> y030737> BUT, why can it use the same message-id with clientA?  does
> y030737> it mean the message-id only increasing in the session which
> y030737> it belonged?
> 
> The server won't care that the message-ids are the same.  There is no
> need for uniqueness.  It's only the clients that will likely need them
> to be different, and only for their own messages.
> 
> [note that all the examples in the document use the same message ID.
> I personally don't think this is helpful, but I didn't spend the
> effort writing the document ;-]
> 
Regards,
/david t. perkins


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>