[Red5devs] Handshaking...

[Steven Zimmer]

Hello,

 

First a really simple question what does 0x03 mean? Does it tell the client
that this is a new packet? It seems this is added to the buffer every time
something new is sent.

 

 

For reference is is the rubyizumi code: 

   def handshake

      @sock.read(1)

      c_handcheck = @sock.read(HandshakeSize)

      @sock.write( "\3" << HandshakeServer <<
Handshake.get_handshake(c_handcheck ))

      @sock.read(HandshakeSize)

      IzumiLogger.debug "<> handshaked"

    end

 

 

I need the bytes from these lines in RTMPProtocolDecoder.java(I'm assuming
this is the c_handcheck from the ruby code) 

 

                              final ByteBuffer hs =
ByteBuffer.allocate(HANDSHAKE_SIZE);

                              in.get(); // skip the header byte

                              BufferUtils.put(hs, in, HANDSHAKE_SIZE);

                              hs.flip();

 

These bytes are needed in the handshake info sent to the client here..

 

 

 

 

in RTMPMinaIoHandler.java:

 

with sessionOpened

                  log.debug("Handshake 1st phase");

                  ByteBuffer out =
ByteBuffer.allocate(Constants.HANDSHAKE_SIZE+1);

                  

                  I think this part is the "\3" from the above ruby code.

 

                  out.put((byte)0x03); 

 

                  This is where that byte array(HandshakeServer[]) needs to
be sent instead of byte array of 0x00   

 

                  out.fill((byte)0x00,Constants.HANDSHAKE_SIZE);

                  out.flip();

                  session.write(out);

 

After this we move to rawBufferRecieved ( I think )

 

I'm assuming since RTMPProtocol decoder changes the state of RTMP that the
ByteBuffer in will be the bytes that I need from above. It is during these
handshake steps that I need to do the Handshake.get_handshake step and send
that back to the client.

 

 

 

Now what I find puzzling is that RTMP will always be in MODE_SERVER so this
code block is puzzling, as we only ever get to the 2nd phase of handshaking.
I've tested this and it seems to be true. This is a good thing for me though
because when I look at the rubyizumi code there shouldn't be this "3rd phase
of handshaking. Why are we testing the mode if it will always been in
MODE_SERVER?

 

    protected void rawBufferRecieved(ProtocolState state, ByteBuffer in,

                  IoSession session) {

 

            final RTMP rtmp = (RTMP) state;

            if (rtmp.getMode() == RTMP.MODE_SERVER) {

                  if (rtmp.getState() != RTMP.STATE_HANDSHAKE) {

                        log.warn("Raw buffer after handshake, something odd
going on");

                  }

                  System.out.println("I do get here");

                  log.debug("Handshake 2nd phase - size: {}",
in.remaining());

                  ByteBuffer out =
ByteBuffer.allocate((Constants.HANDSHAKE_SIZE*2)+1);

                  out.put((byte)0x03);

                  // TODO: the first four bytes of the handshake reply seem
to be the

                  //       server uptime - send something better here...

                  out.putInt(0x01);

                  out.fill((byte)0x00,Constants.HANDSHAKE_SIZE-4);

                  out.put(in);

                  out.flip();

                  // Skip first 8 bytes when comparing the handshake, they
seem to

                  // be changed when connecting from a Mac client.

                  rtmp.setHandshake(out, 9, Constants.HANDSHAKE_SIZE-8);

                  //in.release();

                  session.write(out);

            } else {

                  System.out.println("I Never get here");

                  log.debug("Handshake 3d phase - size: {}",
in.remaining());

                  in.skip(1);

                  ByteBuffer out =
ByteBuffer.allocate(Constants.HANDSHAKE_SIZE);

                  int limit=in.limit();

                  in.limit(in.position()+Constants.HANDSHAKE_SIZE);

                  out.put(in);

                  out.flip();

                  in.limit(limit);

                  in.skip(Constants.HANDSHAKE_SIZE);

                  session.write(out);

            }

      }

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20080707/d6cb5b8d/attachment-0001.html