Re: [hybi] hum #3: Message

Martin Sustrik <sustrik@250bpm.com> Mon, 09 August 2010 16:47 UTC

Return-Path: <sustrik@250bpm.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1902928C10B for <hybi@core3.amsl.com>; Mon, 9 Aug 2010 09:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.646
X-Spam-Level: *
X-Spam-Status: No, score=1.646 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSX-ViQ4xrAG for <hybi@core3.amsl.com>; Mon, 9 Aug 2010 09:47:41 -0700 (PDT)
Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by core3.amsl.com (Postfix) with ESMTP id 2D8973A6B0D for <hybi@ietf.org>; Mon, 9 Aug 2010 09:47:41 -0700 (PDT)
Received: from [10.9.1.2] (chello089173040080.chello.sk [89.173.40.80]) by mail.moloch.sk (Postfix) with ESMTPSA id 6CEA1183420F for <hybi@ietf.org>; Mon, 9 Aug 2010 18:48:14 +0200 (CEST)
Message-ID: <4C6030B8.6040405@250bpm.com>
Date: Mon, 09 Aug 2010 18:45:44 +0200
From: Martin Sustrik <sustrik@250bpm.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: hybi@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] hum #3: Message
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2010 16:47:42 -0000

Greg,

 > However, I do like having a very small minimal frame size for short
 > messages, so I would modify Johns proposal to:
 >
 >  1 bit - fragment
 >  2 bits - reserved
 >  5 bits - opcode
 >  8 bits - short length
 >  [if length = 255: 6 bytes length]
 >  length bytes of payload

Length should definitely go first. That way you can implement a simple 
frame reading/writing layer (in SW or HW) without bothering about all 
the other bits:

   8 bits - short length
   [if length = 255: 6 bytes length]
   length bytes of payload
   1 bit - fragment
   2 bits - reserved
   5 bits - opcode

Martin