Implement WebrtcTransport

Implement WebrtcTransport

This is an initial portion of the new WebRTC-based protocol. The
new Transport implementation can establish connection but doesn't
send any data yet.

BUG=547158
Committed: https://crrev.com/c661e6bbc53491be1e227b92ca39dfab65107039
Cr-Commit-Position: refs/heads/master@{#360491}

[Sergey Ulanov, 2015-11-03 22:33:29]

Description was changed from

==========
Implemente WebrtcTransport

BUG=547158
==========

to

==========
Implement WebrtcTransport

BUG=547158
==========

[Sergey Ulanov, 2015-11-10 23:53:42]

Description was changed from

==========
Implement WebrtcTransport

BUG=547158
==========

to

==========
Implement WebrtcTransport

This is a initial portion of the new WebRTC-based protocol. The
new Transport implementation can establish connection but doesn't
send any data yet.

BUG=547158
==========

[Sergey Ulanov, 2015-11-10 23:53:42]

sergeyu@chromium.org changed reviewers:
+ kelvinp@chromium.org

[kelvinp, 2015-11-11 23:38:48]

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
File remoting/protocol/webrtc_transport.cc (right):

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
remoting/protocol/webrtc_transport.cc:125: // FIXME: use authenticator.
Should this be a TODO statement so that it is consistent with above?

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
remoting/protocol/webrtc_transport.cc:296:
event_handler_->OnOutgoingTransportInfo(transport_info.Pass());
Do we need to post back to the caller thread?

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
File remoting/protocol/webrtc_transport.h (right):

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
remoting/protocol/webrtc_transport.h:32: void Start(EventHandler* event_handler,
Is it guaranteed that the event_handler will always be called in the caller
thread?

[Sergey Ulanov, 2015-11-17 01:40:32]

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
File remoting/protocol/webrtc_transport.cc (right):

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
remoting/protocol/webrtc_transport.cc:125: // FIXME: use authenticator.
On 2015/11/11 23:38:48, kelvinp wrote:
> Should this be a TODO statement so that it is consistent with above?

Done.

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
remoting/protocol/webrtc_transport.cc:296:
event_handler_->OnOutgoingTransportInfo(transport_info.Pass());
On 2015/11/11 23:38:48, kelvinp wrote:
> Do we need to post back to the caller thread?

No. All code in this class runs on the network thread. The worker thread is used
by WebRTC internally. Added ThreadChecker and DCHECKs now.

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
File remoting/protocol/webrtc_transport.h (right):

https://codereview.chromium.org/1427003009/diff/40001/remoting/protocol/webrt...
remoting/protocol/webrtc_transport.h:32: void Start(EventHandler* event_handler,
On 2015/11/11 23:38:48, kelvinp wrote:
> Is it guaranteed that the event_handler will always be called in the caller
> thread?

Yes. Transport is a single-threaded interface that's used only on the network
thread. It the default threading semantics for all code in remoting/protocol.

[kelvinp1, 2015-11-17 01:47:57]

kelvinp@google.com changed reviewers:
+ kelvinp@google.com

[kelvinp1, 2015-11-17 01:47:57]

lgtm

[Sergey Ulanov, 2015-11-17 06:50:40]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2015-11-17 06:50:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427003009/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427003009/60001

[Sergey Ulanov, 2015-11-17 06:51:01]

The CQ bit was unchecked by sergeyu@chromium.org

[Sergey Ulanov, 2015-11-17 06:51:21]

Description was changed from

==========
Implement WebrtcTransport

This is a initial portion of the new WebRTC-based protocol. The
new Transport implementation can establish connection but doesn't
send any data yet.

BUG=547158
==========

to

==========
Implement WebrtcTransport

This is an initial portion of the new WebRTC-based protocol. The
new Transport implementation can establish connection but doesn't
send any data yet.

BUG=547158
==========

[Sergey Ulanov, 2015-11-17 06:51:59]

On 2015/11/17 01:47:57, kelvinp1 wrote:
> lgtm

Can you please rubberstamp from your chromium.org account?

[Sergey Ulanov, 2015-11-17 18:11:26]

The CQ bit was checked by sergeyu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-17 18:12:07]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427003009/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427003009/80001

[commit-bot: I haz the power, 2015-11-17 18:22:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-17 18:22:52]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[kelvinp, 2015-11-18 01:21:03]

kelvinp@chromium.org changed reviewers:
- kelvinp@google.com

[kelvinp, 2015-11-18 01:21:04]

lgtm

[Sergey Ulanov, 2015-11-18 01:34:26]

The CQ bit was checked by sergeyu@chromium.org

[Sergey Ulanov, 2015-11-18 01:34:26]

The patchset sent to the CQ was uploaded after l-g-t-m from kelvinp@google.com,
kelvinp@chromium.org
Link to the patchset: https://codereview.chromium.org/1427003009/#ps100001
(title: " ")

[commit-bot: I haz the power, 2015-11-18 01:38:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427003009/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427003009/100001

[commit-bot: I haz the power, 2015-11-18 01:46:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 01:46:08]

Try jobs failed on following builders:
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[Sergey Ulanov, 2015-11-18 19:29:36]

The CQ bit was checked by sergeyu@chromium.org

[Sergey Ulanov, 2015-11-18 19:29:36]

The patchset sent to the CQ was uploaded after l-g-t-m from kelvinp@google.com,
kelvinp@chromium.org
Link to the patchset: https://codereview.chromium.org/1427003009/#ps120001
(title: " ")

[commit-bot: I haz the power, 2015-11-18 19:30:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427003009/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427003009/120001

[commit-bot: I haz the power, 2015-11-18 19:59:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 19:59:26]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Sergey Ulanov, 2015-11-18 20:55:34]

The CQ bit was checked by sergeyu@chromium.org

[Sergey Ulanov, 2015-11-18 20:55:34]

The patchset sent to the CQ was uploaded after l-g-t-m from kelvinp@google.com,
kelvinp@chromium.org
Link to the patchset: https://codereview.chromium.org/1427003009/#ps140001
(title: " ")

[commit-bot: I haz the power, 2015-11-18 20:56:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427003009/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427003009/140001

[commit-bot: I haz the power, 2015-11-18 22:10:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 22:10:59]

Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Sergey Ulanov, 2015-11-19 00:01:19]

The CQ bit was checked by sergeyu@chromium.org

[Sergey Ulanov, 2015-11-19 00:01:19]

The patchset sent to the CQ was uploaded after l-g-t-m from kelvinp@google.com,
kelvinp@chromium.org
Link to the patchset: https://codereview.chromium.org/1427003009/#ps160001
(title: " ")

[commit-bot: I haz the power, 2015-11-19 00:08:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427003009/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427003009/160001

[Sergey Ulanov, 2015-11-19 00:12:55]

The CQ bit was checked by sergeyu@chromium.org

[Sergey Ulanov, 2015-11-19 00:12:55]

The patchset sent to the CQ was uploaded after l-g-t-m from kelvinp@google.com,
kelvinp@chromium.org
Link to the patchset: https://codereview.chromium.org/1427003009/#ps180001
(title: " ")

[commit-bot: I haz the power, 2015-11-19 00:16:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427003009/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427003009/180001

[commit-bot: I haz the power, 2015-11-19 02:24:08]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2015-11-19 02:24:58]

Patchset 10 (id:??) landed as
https://crrev.com/c661e6bbc53491be1e227b92ca39dfab65107039
Cr-Commit-Position: refs/heads/master@{#360491}

[halliwell, 2015-11-19 16:21:40]

halliwell@chromium.org changed reviewers:
+ halliwell@chromium.org

[halliwell, 2015-11-19 16:21:41]

https://codereview.chromium.org/1427003009/diff/180001/remoting/remoting.gyp
File remoting/remoting.gyp (right):

https://codereview.chromium.org/1427003009/diff/180001/remoting/remoting.gyp#...
remoting/remoting.gyp:241:
'../third_party/libjingle/libjingle.gyp:libpeerconnection',
This appears to be breaking builds where enable_webrtc == 0.

[Sergey Ulanov, 2015-11-19 19:28:21]

https://codereview.chromium.org/1427003009/diff/180001/remoting/remoting.gyp
File remoting/remoting.gyp (right):

https://codereview.chromium.org/1427003009/diff/180001/remoting/remoting.gyp#...
remoting/remoting.gyp:241:
'../third_party/libjingle/libjingle.gyp:libpeerconnection',
On 2015/11/19 16:21:41, halliwell wrote:
> This appears to be breaking builds where enable_webrtc == 0.

What's the reason you need to disable webrtc? Do you need to build remoting with
webrtc disabled? If not then you should also disable remoting: enable_remoting=0

[halliwell, 2015-11-20 04:44:46]

https://codereview.chromium.org/1427003009/diff/180001/remoting/remoting.gyp
File remoting/remoting.gyp (right):

https://codereview.chromium.org/1427003009/diff/180001/remoting/remoting.gyp#...
remoting/remoting.gyp:241:
'../third_party/libjingle/libjingle.gyp:libpeerconnection',
On 2015/11/19 19:28:21, Sergey Ulanov wrote:
> On 2015/11/19 16:21:41, halliwell wrote:
> > This appears to be breaking builds where enable_webrtc == 0.
> 
> What's the reason you need to disable webrtc? Do you need to build remoting
with
> webrtc disabled? If not then you should also disable remoting:
enable_remoting=0

If you need to use targets that are guarded by enable_webrtc, you should use
that condition here too.  But I guess it got fixed already here
https://codereview.chromium.org/1457793004