WebSocketFrameChunk should use IOBuffer to hold data

net/websockets/websocket_frame.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef NET_WEBSOCKETS_WEBSOCKET_FRAME_H_
 #define NET_WEBSOCKETS_WEBSOCKET_FRAME_H_
 
 #include <vector>
 
 #include "base/basictypes.h"
+#include "base/memory/ref_counted.h"
 #include "base/memory/scoped_ptr.h"
 #include "net/base/net_export.h"
 
 namespace net {
 
+class IOBuffer;
+
 // Represents a WebSocket frame header.
 //
 // Members of this class correspond to each element in WebSocket frame header
 // (see http://tools.ietf.org/html/rfc6455#section-5.2).
 struct NET_EXPORT_PRIVATE WebSocketFrameHeader {
   typedef int OpCode;
   static const OpCode kOpCodeContinuation;
   static const OpCode kOpCodeText;
   static const OpCode kOpCodeBinary;
   static const OpCode kOpCodeClose;
@@ skipping 41 matching lines @@
   ~WebSocketFrameChunk();
 
   // Non-null |header| is provided only if this chunk is the first part of
   // a series of chunks.
   scoped_ptr<WebSocketFrameHeader> header;
 
   // Indicates this part is the last chunk of a frame.
   bool final_chunk;
 
   // |data| is always unmasked even if the frame is masked.
-  std::vector<char> data;
+  scoped_refptr<IOBuffer> data;
+
+  // |size| represents size of |data| in bytes.
+  uint64_t size;

[mmenke, 2012/07/26 14:44:45]

Do we really need a 64-bit unsigned integer for size?  My feeling is that unless
we're actually going to support chunks that large, and plumb the support all the
way through, then we should use use ints.  Makes it much clearer that we don't
actually support huge chunks, and the limits the code should check for.

Our socket classes don't support either reads or writes greater than MAX_INT,
anyways, so we'd either have to handle breaking up a huge number into ints when
sending it (A waste of time, easy to get wrong, and something we're not going to
have unit tests for), or explicitly not support numbers that large further down
the pipe, anyways.

May just want to use IOBufferWithSize.

[Yuta Kitamura, 2012/07/27 08:01:08]

Agreed, at least |size| should be an int.

I think the trade off between IOBuffer+int and IOBufferWithSize here is:
- With IOBuffer+int we can use any subclass of IOBuffer for |data|.
- With IOBufferWithSize we should always use IOBufferWithSize.

I don't think of any use case that requires the flexibility of the former, so
IOBufferWithSize would be just fine.

[Takashi Toyoshima, 2012/07/27 10:28:43]

This payload data represents a object in JavaScript, and it's impossible to
handle a large object which size is over 32-bit. So, I agreed to use
IOBufferWithSize here.

 };
 
 // Contains four-byte data representing "masking key" of WebSocket frames.
 struct WebSocketMaskingKey {
   char key[WebSocketFrameHeader::kMaskingKeyLength];
 };
 
 // Writes wire format of a WebSocket frame header into |output|, and returns
 // the number of bytes written.
 //
@@ skipping 33 matching lines @@
 // used for unmasking a WebSocket frame.
 NET_EXPORT_PRIVATE void MaskWebSocketFramePayload(
     const WebSocketMaskingKey& masking_key,
     uint64 frame_offset,
     char* data,
     int data_size);
 
 }  // namespace net
 
 #endif  // NET_WEBSOCKETS_WEBSOCKET_FRAME_H_