Introduce PPB_TCPSocket_Dev.

Introduce PPB_TCPSocket_Dev.

This change exposes the PPB_TCPSocket_Dev interface and makes it to share the same backend as PPB_TCPSocket_Private.

It doesn't include:
- apps permission check;
- TCP socket options that PPB_TCPSocket_Private doesn't support.
These will be implemented in separate CLs.

BUG=247225
TEST=newly added test_tcp_socket.{h,cc}.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=206014

[yzshen1, 2013-06-07 20:19:13]

Hi, David.

Would you please take a look at this CL?

This change makes PPB_TCPSocket_Dev and PPB_TCPSocket_Private to share the same
backend. I haven't added new things such as Apps permission check or extra
socket options. Those will be in later CLs.

The PPB_TCPSocket_Private implementation is still using the "old" proxy/impl
design. I didn't change it to the new design. I wish I could do the refactoring
work later.

The only thing that I refactored, is to move most of the code in
tcp_socket_private_impl into tcp_socket_shared, so that it can be reused by
ppb_tcp_socket_proxy.

Thanks!

[dmichael (off chromium), 2013-06-10 22:31:35]

https://codereview.chromium.org/16667002/diff/1/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/16667002/diff/1/ppapi/proxy/ppapi_messages.h#...
ppapi/proxy/ppapi_messages.h:1172:
IPC_SYNC_MESSAGE_CONTROL2_1(PpapiHostMsg_PPBTCPSocket_Create,
I'm a little concerned about using the same exact backend with no checking of
dev vs private permissions. A compromised renderer will be able to use the SSL
stuff (not sure if that's a security concern or not). But in any case it's
strange that creation of PPB_TCPSocket_Dev is governed by whether private
interfaces are allowed.

https://codereview.chromium.org/16667002/diff/11001/ppapi/proxy/ppb_tcp_socke...
File ppapi/proxy/ppb_tcp_socket_proxy.h (right):

https://codereview.chromium.org/16667002/diff/11001/ppapi/proxy/ppb_tcp_socke...
ppapi/proxy/ppb_tcp_socket_proxy.h:23: PPB_TCPSocket_Proxy(Dispatcher*
dispatcher);
nit: explicit

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
File ppapi/shared_impl/tcp_socket_shared.cc (right):

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.cc:87: int32_t
TCPSocketShared::SSLHandshakeImpl(
Do you still need the SSLHandshake stuff, given that we're not supporting it
initially?

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.cc:260: GetOwnerResource()->pp_instance(),
If you can get rid of SSL stuff, I think you can also get rid of
GetOwnerResource (maybe other stuff too?)

[yzshen1, 2013-06-11 15:05:48]

https://codereview.chromium.org/16667002/diff/1/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/16667002/diff/1/ppapi/proxy/ppapi_messages.h#...
ppapi/proxy/ppapi_messages.h:1172:
IPC_SYNC_MESSAGE_CONTROL2_1(PpapiHostMsg_PPBTCPSocket_Create,
I agree that we must check permissions at the backend to distinguish the dev and
private API.
I haven't added the code to do the apps permission check yet. I am planning to
do the work in a separate CL.

I think we need to make sure that the SSL related code is disallowed for
non-whitelisted apps; other operations can be allowed for both apps with
permission and whitelisted apps.

> But in any case it's strange that creation of
> PPB_TCPSocket_Dev is governed by whether private
> interfaces are allowed.
The creation of PPB_TCPSocket_Dev is not governed by whether private interfaces
are allowed.

The current backend in the browser process doesn't check anything when creating
a socket object. In other words, anyone can create private socket resources, the
problem is that those non-whitelisted apps will fail when calling
connect/sendto/listen.

On 2013/06/10 22:31:35, dmichael wrote:
> I'm a little concerned about using the same exact backend with no checking of
> dev vs private permissions. A compromised renderer will be able to use the SSL
> stuff (not sure if that's a security concern or not). But in any case it's
> strange that creation of PPB_TCPSocket_Dev is governed by whether private
> interfaces are allowed.

https://codereview.chromium.org/16667002/diff/11001/ppapi/proxy/ppb_tcp_socke...
File ppapi/proxy/ppb_tcp_socket_proxy.h (right):

https://codereview.chromium.org/16667002/diff/11001/ppapi/proxy/ppb_tcp_socke...
ppapi/proxy/ppb_tcp_socket_proxy.h:23: PPB_TCPSocket_Proxy(Dispatcher*
dispatcher);
On 2013/06/10 22:31:35, dmichael wrote:
> nit: explicit

Done.

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
File ppapi/shared_impl/tcp_socket_shared.cc (right):

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.cc:87: int32_t
TCPSocketShared::SSLHandshakeImpl(
Because this class is shared by the dev interface and the private interface, I
still put the SSL stuff here.

I considered moving this part to TCPSocketPrivateImpl (which is the base class
of tcp socket private impl and proxy), then we need to do things such as
defining DisconnectImpl as virtual method, so that TCPSocketPrivateImpl can
override it and cancel the hand shake callback.
It also needs to override ReadImpl/WriteImpl because they check the hand shake
callback as well.

Now that we will refactor the implementation later to use the new resource/host
structure, I personally prefer to do the splitting work later.

What do you think?

On 2013/06/10 22:31:35, dmichael wrote:
> Do you still need the SSLHandshake stuff, given that we're not supporting it
> initially?

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.cc:260: GetOwnerResource()->pp_instance(),
Yes. That will be one benefit. (Please see my comments above for the reasons of
keeping the ssl stuff here.)
On 2013/06/10 22:31:35, dmichael wrote:
> If you can get rid of SSL stuff, I think you can also get rid of
> GetOwnerResource (maybe other stuff too?)

[yzshen1, 2013-06-11 15:05:48]

https://codereview.chromium.org/16667002/diff/1/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/16667002/diff/1/ppapi/proxy/ppapi_messages.h#...
ppapi/proxy/ppapi_messages.h:1172:
IPC_SYNC_MESSAGE_CONTROL2_1(PpapiHostMsg_PPBTCPSocket_Create,
I agree that we must check permissions at the backend to distinguish the dev and
private API.
I haven't added the code to do the apps permission check yet. I am planning to
do the work in a separate CL.

I think we need to make sure that the SSL related code is disallowed for
non-whitelisted apps; other operations can be allowed for both apps with
permission and whitelisted apps.

> But in any case it's strange that creation of
> PPB_TCPSocket_Dev is governed by whether private
> interfaces are allowed.
The creation of PPB_TCPSocket_Dev is not governed by whether private interfaces
are allowed.

The current backend in the browser process doesn't check anything when creating
a socket object. In other words, anyone can create private socket resources, the
problem is that those non-whitelisted apps will fail when calling
connect/sendto/listen.

On 2013/06/10 22:31:35, dmichael wrote:
> I'm a little concerned about using the same exact backend with no checking of
> dev vs private permissions. A compromised renderer will be able to use the SSL
> stuff (not sure if that's a security concern or not). But in any case it's
> strange that creation of PPB_TCPSocket_Dev is governed by whether private
> interfaces are allowed.

https://codereview.chromium.org/16667002/diff/11001/ppapi/proxy/ppb_tcp_socke...
File ppapi/proxy/ppb_tcp_socket_proxy.h (right):

https://codereview.chromium.org/16667002/diff/11001/ppapi/proxy/ppb_tcp_socke...
ppapi/proxy/ppb_tcp_socket_proxy.h:23: PPB_TCPSocket_Proxy(Dispatcher*
dispatcher);
On 2013/06/10 22:31:35, dmichael wrote:
> nit: explicit

Done.

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
File ppapi/shared_impl/tcp_socket_shared.cc (right):

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.cc:87: int32_t
TCPSocketShared::SSLHandshakeImpl(
Because this class is shared by the dev interface and the private interface, I
still put the SSL stuff here.

I considered moving this part to TCPSocketPrivateImpl (which is the base class
of tcp socket private impl and proxy), then we need to do things such as
defining DisconnectImpl as virtual method, so that TCPSocketPrivateImpl can
override it and cancel the hand shake callback.
It also needs to override ReadImpl/WriteImpl because they check the hand shake
callback as well.

Now that we will refactor the implementation later to use the new resource/host
structure, I personally prefer to do the splitting work later.

What do you think?

On 2013/06/10 22:31:35, dmichael wrote:
> Do you still need the SSLHandshake stuff, given that we're not supporting it
> initially?

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.cc:260: GetOwnerResource()->pp_instance(),
Yes. That will be one benefit. (Please see my comments above for the reasons of
keeping the ssl stuff here.)
On 2013/06/10 22:31:35, dmichael wrote:
> If you can get rid of SSL stuff, I think you can also get rid of
> GetOwnerResource (maybe other stuff too?)

[yzshen1, 2013-06-11 15:11:26]

Hi,

Would you please do an OWNER review for this?

Brett: content/ppapi_plugin/ppapi_thread.cc
Ben: native_client_sdk/src/build_tools/sdk_files.list

Thanks!

[dmichael (off chromium), 2013-06-11 18:19:16]

Have you uploaded your latest patchset?

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
File ppapi/shared_impl/tcp_socket_shared.cc (right):

https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.cc:87: int32_t
TCPSocketShared::SSLHandshakeImpl(
On 2013/06/11 15:05:48, yzshen1 wrote:
> Because this class is shared by the dev interface and the private interface, I
> still put the SSL stuff here.
> 
> I considered moving this part to TCPSocketPrivateImpl (which is the base class
> of tcp socket private impl and proxy), then we need to do things such as
> defining DisconnectImpl as virtual method, so that TCPSocketPrivateImpl can
> override it and cancel the hand shake callback.
> It also needs to override ReadImpl/WriteImpl because they check the hand shake
> callback as well.
> 
> Now that we will refactor the implementation later to use the new
resource/host
> structure, I personally prefer to do the splitting work later.
> 
> What do you think?
> 
> On 2013/06/10 22:31:35, dmichael wrote:
> > Do you still need the SSLHandshake stuff, given that we're not supporting it
> > initially?
> 
That sounds fine.

By the way, I don't know if you've looked at the host side, but all the messages
are handled directly in PepperMessageFilter. I think we should fix that too
(later, of course).

[yzshen1, 2013-06-11 18:52:15]

On 2013/06/11 18:19:16, dmichael wrote:
> Have you uploaded your latest patchset?
I just uploaded a new patchset.
(Not a lot of changes, just added 'explicit'.)

> 
>
https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
> File ppapi/shared_impl/tcp_socket_shared.cc (right):
> 
>
https://codereview.chromium.org/16667002/diff/11001/ppapi/shared_impl/tcp_soc...
> ppapi/shared_impl/tcp_socket_shared.cc:87: int32_t
> TCPSocketShared::SSLHandshakeImpl(
> On 2013/06/11 15:05:48, yzshen1 wrote:
> > Because this class is shared by the dev interface and the private interface,
I
> > still put the SSL stuff here.
> > 
> > I considered moving this part to TCPSocketPrivateImpl (which is the base
class
> > of tcp socket private impl and proxy), then we need to do things such as
> > defining DisconnectImpl as virtual method, so that TCPSocketPrivateImpl can
> > override it and cancel the hand shake callback.
> > It also needs to override ReadImpl/WriteImpl because they check the hand
shake
> > callback as well.
> > 
> > Now that we will refactor the implementation later to use the new
> resource/host
> > structure, I personally prefer to do the splitting work later.
> > 
> > What do you think?
> > 
> > On 2013/06/10 22:31:35, dmichael wrote:
> > > Do you still need the SSLHandshake stuff, given that we're not supporting
it
> > > initially?
> > 
> That sounds fine.
> 
> By the way, I don't know if you've looked at the host side, but all the
messages
> are handled directly in PepperMessageFilter. I think we should fix that too
> (later, of course).
Yes, we will need to change it to be a resource host. :)

[dmichael (off chromium), 2013-06-11 21:15:26]

Just some nits. lgtm

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
File ppapi/api/dev/ppb_tcp_socket_dev.idl (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
ppapi/api/dev/ppb_tcp_socket_dev.idl:62: * Connects to an address given by
|addr|.
which is a PPB_NetAddress_Dev resource?

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
ppapi/api/dev/ppb_tcp_socket_dev.idl:69: * Gets the local address of the socket,
if it has been connected.
Probably ought to mention that it returns a PPB_NetAddress_Dev PP_Resource. Same
for GetRemoteAddress.

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
ppapi/api/dev/ppb_tcp_socket_dev.idl:85: * Multiple outstanding read requests
are not supported.
nit: I would put a blank comment line if this is a new paragraph. (Same for
Write)

https://codereview.chromium.org/16667002/diff/27001/ppapi/cpp/dev/tcp_socket_...
File ppapi/cpp/dev/tcp_socket_dev.h (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/cpp/dev/tcp_socket_...
ppapi/cpp/dev/tcp_socket_dev.h:38: NetAddress_Dev GetRemoteAddress();
Arguably, these could be const

https://codereview.chromium.org/16667002/diff/27001/ppapi/cpp/dev/tcp_socket_...
ppapi/cpp/dev/tcp_socket_dev.h:48: const CompletionCallback& callback);
Optional suggestion...  we could add an overload (or separately named function)
that doesn't take a CompletionCallback. Under the hood, it would just provide a
do-nothing callback. As long as you get your parameters right, there shouldn't
really be any need to wait for the callback normally. If you Read or Write while
the SetOption is pending, the option should apply.

It seems like we could almost leave out the callback in the C API entirely. Not
a big deal, though.

https://codereview.chromium.org/16667002/diff/27001/ppapi/shared_impl/tcp_soc...
File ppapi/shared_impl/tcp_socket_shared.h (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.h:24: public:
It seems like most of the stuff below could/should be protected:

https://codereview.chromium.org/16667002/diff/27001/ppapi/tests/test_tcp_sock...
File ppapi/tests/test_tcp_socket.cc (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/tests/test_tcp_sock...
ppapi/tests/test_tcp_socket.cc:132: s->push_back(buffer[i]);
optional: I would maybe use string::copy instead of reserve/push_back

https://codereview.chromium.org/16667002/diff/27001/webkit/plugins/ppapi/reso...
File webkit/plugins/ppapi/resource_creation_impl.cc (right):

https://codereview.chromium.org/16667002/diff/27001/webkit/plugins/ppapi/reso...
webkit/plugins/ppapi/resource_creation_impl.cc:210: return 0;  // Not supported
in-process.
NOTIMPLEMENTED()?

[yzshen1, 2013-06-12 05:20:54]

Thanks David!

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
File ppapi/api/dev/ppb_tcp_socket_dev.idl (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
ppapi/api/dev/ppb_tcp_socket_dev.idl:62: * Connects to an address given by
|addr|.
On 2013/06/11 21:15:26, dmichael wrote:
> which is a PPB_NetAddress_Dev resource?

Done.

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
ppapi/api/dev/ppb_tcp_socket_dev.idl:69: * Gets the local address of the socket,
if it has been connected.
On 2013/06/11 21:15:26, dmichael wrote:
> Probably ought to mention that it returns a PPB_NetAddress_Dev PP_Resource.
Same
> for GetRemoteAddress.

Done.

https://codereview.chromium.org/16667002/diff/27001/ppapi/api/dev/ppb_tcp_soc...
ppapi/api/dev/ppb_tcp_socket_dev.idl:85: * Multiple outstanding read requests
are not supported.
On 2013/06/11 21:15:26, dmichael wrote:
> nit: I would put a blank comment line if this is a new paragraph. (Same for
> Write)

Done.

https://codereview.chromium.org/16667002/diff/27001/ppapi/cpp/dev/tcp_socket_...
File ppapi/cpp/dev/tcp_socket_dev.h (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/cpp/dev/tcp_socket_...
ppapi/cpp/dev/tcp_socket_dev.h:38: NetAddress_Dev GetRemoteAddress();
On 2013/06/11 21:15:26, dmichael wrote:
> Arguably, these could be const

Done.

https://codereview.chromium.org/16667002/diff/27001/ppapi/cpp/dev/tcp_socket_...
ppapi/cpp/dev/tcp_socket_dev.h:48: const CompletionCallback& callback);
On 2013/06/11 21:15:26, dmichael wrote:
> Optional suggestion...  we could add an overload (or separately named
function)
> that doesn't take a CompletionCallback. Under the hood, it would just provide
a
> do-nothing callback. As long as you get your parameters right, there shouldn't
> really be any need to wait for the callback normally. If you Read or Write
while
> the SetOption is pending, the option should apply.

I think we could add a helper function such as
CompletionCallback CreateDoNothingCallback();

So we can call the method this way:
SetOption(name, value, CreateDoNothingCallback());

That helper can be used by many other C++ APIs as well.


> It seems like we could almost leave out the callback in the C API entirely.
Not
> a big deal, though.

I think in some cases maybe people would like to know whether the SetOption call
succeeds or not. Without a completion callback, we cannot tell users the result,
because the operation needs to happen in the browser process.

https://codereview.chromium.org/16667002/diff/27001/ppapi/shared_impl/tcp_soc...
File ppapi/shared_impl/tcp_socket_shared.h (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/shared_impl/tcp_soc...
ppapi/shared_impl/tcp_socket_shared.h:24: public:
On 2013/06/11 21:15:26, dmichael wrote:
> It seems like most of the stuff below could/should be protected:

Good catch. Thanks!

https://codereview.chromium.org/16667002/diff/27001/ppapi/tests/test_tcp_sock...
File ppapi/tests/test_tcp_socket.cc (right):

https://codereview.chromium.org/16667002/diff/27001/ppapi/tests/test_tcp_sock...
ppapi/tests/test_tcp_socket.cc:132: s->push_back(buffer[i]);
On 2013/06/11 21:15:26, dmichael wrote:
> optional: I would maybe use string::copy instead of reserve/push_back

Thanks!
I tried two different versions:
==================
    std::string buffer_string(buffer, cb.result());
    size_t pos = buffer_string.find('\n');
    if (pos != std::string::npos) {
      s->append(buffer_string, 0, pos + 1);
    } else {
      s->append(buffer_string);
    }
==================
    s->append(buffer, cb.result());
    size_t pos = s->find('\n');
    if (pos != std::string::npos) {
      s->resize(pos + 1);
      return PP_OK;
    }
==================
They don't seem much more clear. So I just kept the original code.

https://codereview.chromium.org/16667002/diff/27001/webkit/plugins/ppapi/reso...
File webkit/plugins/ppapi/resource_creation_impl.cc (right):

https://codereview.chromium.org/16667002/diff/27001/webkit/plugins/ppapi/reso...
webkit/plugins/ppapi/resource_creation_impl.cc:210: return 0;  // Not supported
in-process.
On 2013/06/11 21:15:26, dmichael wrote:
> NOTIMPLEMENTED()?

I think all the methods in this file which return 0 don't have NOTIMPLEMENTED().
So I decided to not have it for consistency.

[commit-bot: I haz the power, 2013-06-12 05:21:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16667002/36001

[binji, 2013-06-12 16:53:38]

native_client_sdk lgtm

[brettw, 2013-06-12 16:59:11]

ppapi_thread LGTM

[commit-bot: I haz the power, 2013-06-12 17:07:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16667002/40001

[commit-bot: I haz the power, 2013-06-12 18:19:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16667002/54001

[commit-bot: I haz the power, 2013-06-12 23:46:34]

Retried try job too often on win_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-06-12 23:56:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16667002/54001

[commit-bot: I haz the power, 2013-06-13 02:58:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16667002/54001

[commit-bot: I haz the power, 2013-06-13 06:48:37]

Change committed as 206014