[stomp-dev] RE: STOMP and connect/connected handshake

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[stomp-dev] RE: STOMP and connect/connected handshake

Mittler, Nathan
There is already a correlation-id header defined in the AMQ extensions:
http://www.activemq.org/site/stomp.html - I was trying to reuse this
header for the connect handshake.  I don't feel that strongly one way or
the other. The name "response-id" is fine - we'd just have to add
another header to our list of extensions (we'd have to do that for the
"command-id" header anyway).

Nate

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Hiram
Chirino
Sent: Monday, June 12, 2006 10:05 AM
To: [hidden email]; [hidden email]
Subject: Re: STOMP and connect/connected handshake

Cross posting to the stomp mailing list too since someone there might
have some input on this.

I like the idea about supporting a command-id header.  I might prefer
the correlation header to be called response-id instead of
correlation-id.

---------- Forwarded message ----------
From: Nathan Mittler <[hidden email]>
Date: Jun 12, 2006 6:13 AM
Subject: STOMP and connect/connected handshake
To: [hidden email]


For the new activemq-cpp library, we need to extend the STOMP
connect/connected handshake so that we get back a correlation-id for our
response correlator.  To do this, we need to send something in the
connect
request that contains a client-defined command-id.  My first thought was
to
just reuse the message-id header, but that is typically reserved for
cases
when a client is expecting to acknowledge a message.  So rather than
risk
breaking that paradigm, I created a new header "command-id" that is just
used on the connect message.  When the broker receives a connect request
with a command-id header, it creates a connected response with a
correlation-id set to the command-id of the original request.  This way
the
client can treat the handshake as a true request/response.

Does anyone see any problems with adding this to the broker?

Regards,
Nate



--
Regards,
Hiram

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: RE: STOMP and connect/connected handshake

James Strachan-2
FWIW the correlation-id currently maps to JMSCorrelationID - but is
only used on JMS messages rather than on commands like CONNECT etc.

Though the JMSCorrelationID is often an out of band correlation;
rather than correlating a request stomp command to a stomp response;
so maybe another header name would avoid confusion?

On 6/12/06, Mittler, Nathan <[hidden email]> wrote:

> There is already a correlation-id header defined in the AMQ extensions:
> http://www.activemq.org/site/stomp.html - I was trying to reuse this
> header for the connect handshake.  I don't feel that strongly one way or
> the other. The name "response-id" is fine - we'd just have to add
> another header to our list of extensions (we'd have to do that for the
> "command-id" header anyway).
>
> Nate
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Hiram
> Chirino
> Sent: Monday, June 12, 2006 10:05 AM
> To: [hidden email]; [hidden email]
> Subject: Re: STOMP and connect/connected handshake
>
> Cross posting to the stomp mailing list too since someone there might
> have some input on this.
>
> I like the idea about supporting a command-id header.  I might prefer
> the correlation header to be called response-id instead of
> correlation-id.
>
> ---------- Forwarded message ----------
> From: Nathan Mittler <[hidden email]>
> Date: Jun 12, 2006 6:13 AM
> Subject: STOMP and connect/connected handshake
> To: [hidden email]
>
>
> For the new activemq-cpp library, we need to extend the STOMP
> connect/connected handshake so that we get back a correlation-id for our
> response correlator.  To do this, we need to send something in the
> connect
> request that contains a client-defined command-id.  My first thought was
> to
> just reuse the message-id header, but that is typically reserved for
> cases
> when a client is expecting to acknowledge a message.  So rather than
> risk
> breaking that paradigm, I created a new header "command-id" that is just
> used on the connect message.  When the broker receives a connect request
> with a command-id header, it creates a connected response with a
> correlation-id set to the command-id of the original request.  This way
> the
> client can treat the handshake as a true request/response.
>
> Does anyone see any problems with adding this to the broker?
>
> Regards,
> Nate
>
>
>
> --
> Regards,
> Hiram
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: RE: STOMP and connect/connected handshake

Mittler, Nathan
In reply to this post by Mittler, Nathan
Agreed.  So let's go with a new set of headers.

I propose the following:

request-id (goes in any STOMP client->broker request command ...
currently only CONNECT)

response-id (goes in any STOMP client<-broker response command ...
currently only CONNECTED)

I've changed "command-id" to "request-id" so that it's clearer that the
two headers are related.

How does this sound?

Nate

-----Original Message-----
From: James Strachan [mailto:[hidden email]]
Sent: Monday, June 12, 2006 10:28 AM
To: [hidden email]
Subject: Re: [stomp-dev] RE: STOMP and connect/connected handshake

FWIW the correlation-id currently maps to JMSCorrelationID - but is
only used on JMS messages rather than on commands like CONNECT etc.

Though the JMSCorrelationID is often an out of band correlation;
rather than correlating a request stomp command to a stomp response;
so maybe another header name would avoid confusion?

On 6/12/06, Mittler, Nathan <[hidden email]> wrote:
> There is already a correlation-id header defined in the AMQ
extensions:
> http://www.activemq.org/site/stomp.html - I was trying to reuse this
> header for the connect handshake.  I don't feel that strongly one way
or

> the other. The name "response-id" is fine - we'd just have to add
> another header to our list of extensions (we'd have to do that for the
> "command-id" header anyway).
>
> Nate
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Hiram
> Chirino
> Sent: Monday, June 12, 2006 10:05 AM
> To: [hidden email]; [hidden email]
> Subject: Re: STOMP and connect/connected handshake
>
> Cross posting to the stomp mailing list too since someone there might
> have some input on this.
>
> I like the idea about supporting a command-id header.  I might prefer
> the correlation header to be called response-id instead of
> correlation-id.
>
> ---------- Forwarded message ----------
> From: Nathan Mittler <[hidden email]>
> Date: Jun 12, 2006 6:13 AM
> Subject: STOMP and connect/connected handshake
> To: [hidden email]
>
>
> For the new activemq-cpp library, we need to extend the STOMP
> connect/connected handshake so that we get back a correlation-id for
our
> response correlator.  To do this, we need to send something in the
> connect
> request that contains a client-defined command-id.  My first thought
was
> to
> just reuse the message-id header, but that is typically reserved for
> cases
> when a client is expecting to acknowledge a message.  So rather than
> risk
> breaking that paradigm, I created a new header "command-id" that is
just
> used on the connect message.  When the broker receives a connect
request
> with a command-id header, it creates a connected response with a
> correlation-id set to the command-id of the original request.  This
way

> the
> client can treat the handshake as a true request/response.
>
> Does anyone see any problems with adding this to the broker?
>
> Regards,
> Nate
>
>
>
> --
> Regards,
> Hiram
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: RE: STOMP and connect/connected handshake

James Strachan-2
+1, sounds great to me

On 6/12/06, Mittler, Nathan <[hidden email]> wrote:

> Agreed.  So let's go with a new set of headers.
>
> I propose the following:
>
> request-id (goes in any STOMP client->broker request command ...
> currently only CONNECT)
>
> response-id (goes in any STOMP client<-broker response command ...
> currently only CONNECTED)
>
> I've changed "command-id" to "request-id" so that it's clearer that the
> two headers are related.
>
> How does this sound?
>
> Nate
>
> -----Original Message-----
> From: James Strachan [mailto:[hidden email]]
> Sent: Monday, June 12, 2006 10:28 AM
> To: [hidden email]
> Subject: Re: [stomp-dev] RE: STOMP and connect/connected handshake
>
> FWIW the correlation-id currently maps to JMSCorrelationID - but is
> only used on JMS messages rather than on commands like CONNECT etc.
>
> Though the JMSCorrelationID is often an out of band correlation;
> rather than correlating a request stomp command to a stomp response;
> so maybe another header name would avoid confusion?
>
> On 6/12/06, Mittler, Nathan <[hidden email]> wrote:
> > There is already a correlation-id header defined in the AMQ
> extensions:
> > http://www.activemq.org/site/stomp.html - I was trying to reuse this
> > header for the connect handshake.  I don't feel that strongly one way
> or
> > the other. The name "response-id" is fine - we'd just have to add
> > another header to our list of extensions (we'd have to do that for the
> > "command-id" header anyway).
> >
> > Nate
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On Behalf Of Hiram
> > Chirino
> > Sent: Monday, June 12, 2006 10:05 AM
> > To: [hidden email]; [hidden email]
> > Subject: Re: STOMP and connect/connected handshake
> >
> > Cross posting to the stomp mailing list too since someone there might
> > have some input on this.
> >
> > I like the idea about supporting a command-id header.  I might prefer
> > the correlation header to be called response-id instead of
> > correlation-id.
> >
> > ---------- Forwarded message ----------
> > From: Nathan Mittler <[hidden email]>
> > Date: Jun 12, 2006 6:13 AM
> > Subject: STOMP and connect/connected handshake
> > To: [hidden email]
> >
> >
> > For the new activemq-cpp library, we need to extend the STOMP
> > connect/connected handshake so that we get back a correlation-id for
> our
> > response correlator.  To do this, we need to send something in the
> > connect
> > request that contains a client-defined command-id.  My first thought
> was
> > to
> > just reuse the message-id header, but that is typically reserved for
> > cases
> > when a client is expecting to acknowledge a message.  So rather than
> > risk
> > breaking that paradigm, I created a new header "command-id" that is
> just
> > used on the connect message.  When the broker receives a connect
> request
> > with a command-id header, it creates a connected response with a
> > correlation-id set to the command-id of the original request.  This
> way
> > the
> > client can treat the handshake as a true request/response.
> >
> > Does anyone see any problems with adding this to the broker?
> >
> > Regards,
> > Nate
> >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email