Add DISABLE_TCP_TRANSPORT flag in the Transport API.

ppapi/c/dev/ppb_transport_dev.h

 /* Copyright (c) 2011 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 PPAPI_C_PPB_TRANSPORT_DEV_H_
 #define PPAPI_C_PPB_TRANSPORT_DEV_H_
 
 #include "ppapi/c/pp_bool.h"
 #include "ppapi/c/pp_completion_callback.h"
 #include "ppapi/c/pp_module.h"
@@ skipping 30 matching lines @@
   // connections.
   PP_TRANSPORTPROPERTY_TCP_SEND_WINDOW = 6,
 
   // Boolean value that disables Neagle's algorithm when set to
   // true. When Neagle's algorithm is disabled, all outgoing packets
   // are sent as soon as possible. When set to false (by default) data
   // may be buffered until there is a sufficient amount to send.
   PP_TRANSPORTPROPERTY_TCP_NO_DELAY = 7,
 
   // Delay for ACK packets in milliseconds. By default set to 100ms.
-  PP_TRANSPORTPROPERTY_TCP_ACK_DELAY = 8
+  PP_TRANSPORTPROPERTY_TCP_ACK_DELAY = 8,
+
+  // Types of ports to use. An integer that is a bit-mast of
+  // PP_TransportPorts values. By default all ports are disabled.

[Wez, 2011/09/13 19:57:19]

It might be better to use the term "protocols" rather than "ports", since the
term "port" relates to the internals of libjingle, whereas what matters to the
caller is the protocols used.

Does it make sense for all ports to be disabled?

[Sergey Ulanov, 2011/09/13 20:31:38]

Ok, I'll change it to protocol.
That was a typo in the comment. By default all are enabled.

+  PP_TRANSPORTPROPERTY_PORT_TYPES = 9
 } PP_TransportProperty;
 PP_COMPILE_ASSERT_SIZE_IN_BYTES(PP_TransportProperty, 4);
 
 typedef enum {
   // RFC5766 compliant relay server.
   PP_TRANSPORTRELAYMODE_TURN = 0,
 
   // Legacy Google relay server.
   PP_TRANSPORTRELAYMODE_GOOGLE = 1
 } PP_TransportRelayMode;
 
+typedef enum {
+  PP_TRANSPORTPORTS_UDP = 1 << 0,
+  PP_TRANSPORTPORTS_TCP = 1 << 1,
+  PP_TRANSPORTPORTS_STUN = 1 << 2,
+  PP_TRANSPORTPORTS_RELAY_UDP = 1 << 3,
+  PP_TRANSPORTPORTS_RELAY_TCP = 1 << 4,
+  PP_TRANSPORTPORTS_RELAY_SSLTCP = 1 << 5,

[Wez, 2011/09/13 19:57:19]

Are we ever likely to want to add more of these, e.g. UDP4 to force IPv4 UDP
once IPv6 is available?

If so then splitting them into blocks might be better, e.g. UDP & TCP in the
lower 16-bits of "direct" types, STUN in an 8-bit block of nat-traversing types,
and the RELAY options in a final 8-bit block of relay types.

[Sergey Ulanov, 2011/09/13 20:31:38]

It's probable that we may want to add more protocols in the future, but I don't
think there is a valid reason to distinguish IPv4 and IPv6 ports, so I don't
think it's worth splitting these in blocks, as we don't know what kind of
protocols we will want to add in the future.

+
+  PP_TRANSPORTPORTS_ALL = 0xFFFFFFFF
+} PP_TransportPorts;
+
 struct PPB_Transport_Dev {
   // Creates a new transport object with the specified name using the
   // specified protocol.
   PP_Resource (*CreateTransport)(PP_Instance instance,
                                  const char* name,
                                  const char* proto);
 
   // Returns PP_TRUE if resource is a Transport, PP_FALSE otherwise.
   PP_Bool (*IsTransport)(PP_Resource resource);
 
@@ skipping 41 matching lines @@
   int32_t (*Send)(PP_Resource transport,
                   const void* data,
                   uint32_t len,
                   struct PP_CompletionCallback cb);
 
   // Disconnects from the remote peer.
   int32_t (*Close)(PP_Resource transport);
 };
 
 #endif  /* PPAPI_C_PPB_TRANSPORT_DEV_H_ */