Trailing new line in frame

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

Trailing new line in frame

Patrick Hurley-2
I am implementing a light weight stomp server in Ruby.

I was looking at the existing Ruby gem of the stomp protocol --
actually I was using it to test my implementation, and noticed that is
requires a newline after the ^@ (null) that terminates the frame.

I do not see this mentioned in the protocol specificaiton, so is the
bug in the gem or the specification?

Thanks
pth

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

David Jones
Looks to me (via the spec page and some Perl modules), that there is no newline after the null:

$string .="\0";


Cheers,
David.


Patrick Hurley-2 wrote
I am implementing a light weight stomp server in Ruby.

I was looking at the existing Ruby gem of the stomp protocol --
actually I was using it to test my implementation, and noticed that is
requires a newline after the ^@ (null) that terminates the frame.

I do not see this mentioned in the protocol specificaiton, so is the
bug in the gem or the specification?

Thanks
pth

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

    http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

brianm
In reply to this post by Patrick Hurley-2

On Oct 13, 2006, at 12:24 PM, Patrick Hurley wrote:

> I am implementing a light weight stomp server in Ruby.
>
> I was looking at the existing Ruby gem of the stomp protocol --
> actually I was using it to test my implementation, and noticed that is
> requires a newline after the ^@ (null) that terminates the frame.

It doesn't require but it does allow. Arbitrary whitespace between  
frames is okay. Poking over the code, it *should* be sending the  
newline (puts) but shouldn't be requiring newline to read the end of  
a frame (it uses read(content-length) if content-length is present,  
otherwise the, rather inefficient, byte-by-byte read.

Are you experiencing different behavior? There are not many stomp  
servers out there, so it is quite possible the existing ones always  
do send the newline and I missed it!

-Brian

> I do not see this mentioned in the protocol specificaiton, so is the
> bug in the gem or the specification?
>
> Thanks
> pth
>
> ---------------------------------------------------------------------
> 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: Trailing new line in frame

Patrick Hurley-2
On 10/16/06, Brian McCallister <[hidden email]> wrote:
> Are you experiencing different behavior? There are not many stomp
> servers out there, so it is quite possible the existing ones always
> do send the newline and I missed it!

I am below is the receieve code from the Ruby client, I "highlighted"
the code towards the bottom that appears to require the newline.

    def _receive( s )
      line = ' '
      @read_semaphore.synchronize do
        line = s.gets
        return NIL if line == NIL
        Message.new do |m|
          m.command = line.chomp
          m.headers = {}
          until (line = s.gets.chomp) == ''
            k = (line.strip[0, line.strip.index(':')]).strip
            v = (line.strip[line.strip.index(':') + 1, line.strip.length]).strip
            m.headers[k] = v
          end

          if (m.headers['content-length'])
            m.body = s.read m.headers['content-length'].to_i
            c = s.getc
            raise "Invalid content length received" unless c == 0
          else
            m.body = ''
            until (c = s.getc) == 0
              m.body << c.chr
            end
          end

################### highlight ##########################
################### highlight ##########################

# at this point we have already read our null frame terminator
# now we wait again for a character and test that it is a newline
# I removing these two lines should address the issue

          c = s.getc
          raise "Invalid frame termination received" unless c == 10

################### highlight ##########################
################### highlight ##########################

        end
      end
    end

Thanks
pth

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

brianm


On Oct 16, 2006, at 8:38 AM, Patrick Hurley wrote:

> I am below is the receieve code from the Ruby client, I "highlighted"
> the code towards the bottom that appears to require the newline.
>
> ################### highlight ##########################
>
> # at this point we have already read our null frame terminator
> # now we wait again for a character and test that it is a newline
> # I removing these two lines should address the issue
>
>          c = s.getc
>          raise "Invalid frame termination received" unless c == 10
>
> ################### highlight ##########################

That is a bug, alright. It reads the null then requires a newline :-/

Good find, thank you!

-Brian

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

Patrick Hurley-2
On 10/16/06, Brian McCallister <[hidden email]> wrote:

>
>
> On Oct 16, 2006, at 8:38 AM, Patrick Hurley wrote:
>
> > I am below is the receieve code from the Ruby client, I "highlighted"
> > the code towards the bottom that appears to require the newline.
> >
> > ################### highlight ##########################
> >
> > # at this point we have already read our null frame terminator
> > # now we wait again for a character and test that it is a newline
> > # I removing these two lines should address the issue
> >
> >          c = s.getc
> >          raise "Invalid frame termination received" unless c == 10
> >
> > ################### highlight ##########################
>
> That is a bug, alright. It reads the null then requires a newline :-/
>
> Good find, thank you!
>
> -Brian
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

Thank you for the original code. FYI I hope to release my stompserver
very soon. Do you have a validation suite you use in testing any of
the exist server(s)? I have been writing unit tests as I go, but
everything is hanging on how I read the spec.

pth

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

brianm

On Oct 16, 2006, at 9:06 AM, Patrick Hurley wrote:

> Thank you for the original code. FYI I hope to release my stompserver
> very soon. Do you have a validation suite you use in testing any of
> the exist server(s)? I have been writing unit tests as I go, but
> everything is hanging on how I read the spec.

It keeps coming up as "something we should do" but I haven't,  
personally, had almost any spare time in the last year (yea, valley  
startup!).

If you have been building a set of tests I would *love* to look at  
using them as the basis of a TCK. The ActiveMQ tests are all a little  
bit too ActiveMQ specific to be useful from just the protocol point  
of view.

-Brian

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

Patrick Hurley-2
On 10/16/06, Brian McCallister <[hidden email]> wrote:
> If you have been building a set of tests I would *love* to look at
> using them as the basis of a TCK. The ActiveMQ tests are all a little
> bit too ActiveMQ specific to be useful from just the protocol point
> of view.

Still very much a work in progress:
svn://rubyforge.org/var/svn/stompserver/trunk
I will be sure to announce here when I release (hopefully before I go
to RubyConf this week :-).

pth

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: Trailing new line in frame

Martin Ronner
In reply to this post by brianm
I remember having been fighting with the conditional NL in the past with
a c client. Especially since ActiveMQ doesn't handle it always the same
way. Sometimes it's there sometimes not.

Means I have to peek for an additional NL after each ^@ (null) and read
it if it's there. Else the next message won't be valid anymore.

I guess the NL has been introduced for Telnet compatibility but I don't
see the advantage of it yet.

-Martin


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

Alan Willis
In reply to this post by Patrick Hurley-2
Re: [stomp-dev] Trailing new line in frame

I've been stripping leading spaces off of the frame including newlines.

-----Original Message-----
From: Martin Ronner <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Tue Oct 17 02:23:53 2006
Subject: RE: [stomp-dev] Trailing new line in frame

I remember having been fighting with the conditional NL in the past with
a c client. Especially since ActiveMQ doesn't handle it always the same
way. Sometimes it's there sometimes not.

Means I have to peek for an additional NL after each ^@ (null) and read
it if it's there. Else the next message won't be valid anymore.

I guess the NL has been introduced for Telnet compatibility but I don't
see the advantage of it yet.

-Martin


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

brianm
In reply to this post by Martin Ronner

On Oct 17, 2006, at 2:23 AM, Martin Ronner wrote:

> I remember having been fighting with the conditional NL in the past  
> with
> a c client. Especially since ActiveMQ doesn't handle it always the  
> same
> way. Sometimes it's there sometimes not.
>
> Means I have to peek for an additional NL after each ^@ (null) and  
> read
> it if it's there. Else the next message won't be valid anymore.
>
> I guess the NL has been introduced for Telnet compatibility but I  
> don't
> see the advantage of it yet.

That (telnet, etc) is exactly (part of) it. Arbitrary whitespace  
between frames is legal. This allows using line-oriented printing  
(though not reading, maybe \0\n would have been a better terminator)  
which is darned handy.

A significant goal is to maximize ease of interoperability :-)

-Brian

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

Patrick Hurley-2
On 10/17/06, Brian McCallister <[hidden email]> wrote:
> That (telnet, etc) is exactly (part of) it. Arbitrary whitespace
> between frames is legal. This allows using line-oriented printing
> (though not reading, maybe \0\n would have been a better terminator)
> which is darned handy.
>
> A significant goal is to maximize ease of interoperability :-)

I understand, but \0\n is allowed, as you allow any amount of white
space between frames. The issue/question is if \0\n is the frame
terminator - or if some of the clients are buggy for requiring  the
\n.

The easiest course right now would be to just make the terminator be
\000\n as that would "fix" the bugs in the clients and it appears the
servers already do this.

pth

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Trailing new line in frame

James Strachan-2
AFAIK the terminator should be \000.

On 10/17/06, Patrick Hurley <[hidden email]> wrote:

> On 10/17/06, Brian McCallister <[hidden email]> wrote:
> > That (telnet, etc) is exactly (part of) it. Arbitrary whitespace
> > between frames is legal. This allows using line-oriented printing
> > (though not reading, maybe \0\n would have been a better terminator)
> > which is darned handy.
> >
> > A significant goal is to maximize ease of interoperability :-)
>
> I understand, but \0\n is allowed, as you allow any amount of white
> space between frames. The issue/question is if \0\n is the frame
> terminator - or if some of the clients are buggy for requiring  the
> \n.
>
> The easiest course right now would be to just make the terminator be
> \000\n as that would "fix" the bugs in the clients and it appears the
> servers already do this.
>
> pth
>
> ---------------------------------------------------------------------
> 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: Trailing new line in frame

snacktime
In reply to this post by brianm

This is interesting.  I have been using the ruby stomp client against activemq and was pulling my hair out for days until I started to write my own simple stomp server and realized what was really going on.  The strange thing is that sometimes the client works and sometimes it doesn't.  I'm guessing that in the client there is usually more than just the current frame to read, so the client always has something after the null character.  But that's just a guess I haven't tested it yet.

Also, there is a bug in activemq with stomp where it will not unregister consumers if the connection ends badly.  It's still there in the latest RC.  I've posted it to the activemq list but no idea if anyone is actually working on it yet.

Chris