298607 - There is no possibility to customize nsISocketTransportService

Status: RESOLVED INVALID

(Core :: Networking, enhancement)

Description

[<<INACTIVE>>]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050610 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050610 Firefox/1.0+

There is no possibility to customize the nsISocketTransportService factory and
let Mozilla use another implementation of nsISocketTransport. We want to
implement a P2P platform in mozilla and a P2P network protocol with integrated
multiplexing, nat-traversing, transparent relay and callback support and more
functionality. 

We discovered usage of nsISocketProvider implementation and figure out this
approach is not efficient for us because of these issues:
-          nsSocketTransport implementation tries in every case to resolve the
given host name using the nsIDNSService implementation. But we have to use the
host name as a “virtual” peer name. This peer name is not the real host name
representing the network address but name of a peer in our virtual network.
-          We haven’t discovered how it is possible to specify a network context
for the socket. We want to instantiate more then one peer representation in one
firefox/mozilla instance. Every instance has its own identity – means btw. peer
certificate for SSL support – and other low level data structures related to
each peer.

From these reasons we decided to implement our own factory implementing
nsISocketTransprotService what instatiates our own implementation of
nsISocketTransport. This approach is really efficent but we loose possibility to
use these features in existing mozilla implementation such as HTTP protocol.

We would like to suggest a way to customize instance of socket transport
service. This may be done by extending signature of nsIChannel::Open and
nsIChannel::AsyncOpen methods. These two methods should take an instance of
socket transport service as an other parameter.

Also there should be possibility to customize instatiation of accepted socket
transports. This could be realized by extending nsISocketTransportService with
new method AcceptTransport. This method will be called from nsIServerSocket what
is also customizable with particular socket transport service throught its Init
and InitWithAddress methods.

If someone can validate this approach, we will propose a patch that adds these
capabilities.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Darin Fisher]

Your proposed solution of extending those methods with a
nsISocketTransportService parameter is not a solution I would suggest.
In fact, I would probably veto that solution flat out.

You should instead look for ways to override the nsISocketTransportService
factory via the XPCOM nsIComponentRegistrar.  Now, I believe that nsIOService
initializes the current nsISocketTransportService implementation very early
during startup, so you might need to make changes there to have it use your
implementation instead of the built-in implementation.

>  nsSocketTransport implementation tries in every case to resolve the
> given host name using the nsIDNSService implementation.

This is not true.  You should study the way that SOCKS v5 with remote host
resolution is implemented.  See nsIProxyInfo.TRANSPARENT_PROXY_RESOLVES_HOST.

I can see why implementing nsISocketProvider may not be the best solution for
your application though.

Comment 2

[<<INACTIVE>>]

We succefully implemented the factory override. We are now able to use our
implementatoin of nsISocketTransportService and nsISocketTransport and
confortably switch back to the original service - thanks for advice!

But there is still other problem. We have no control of creation and management
of accepted sockets. There is hardcoded creation of nsSocketTransport instance
when a new socket has been accepted. This could be overidable with
1) the new method AcceptSocket of nsISocketTransportService
2) a new interface for creating accepted sockets e.g. nsISocketAcceptService

Do you agree with either of these approaches, or do you have another idea about
how to accomplish this? If you can point us in the right direction, we will
propose a patch that implements the preferred solution.

Comment 3

[Darin Fisher]

The implementation of nsIServerSocket is coupled to the implementation of
nsISocketTransportService.  Perhaps you should override the nsIServerSocket
implementation as well.

Please note that there is a very high cost to changing established interfaces,
so I am trying to steer you away from such a route.

Comment 4

[Honza Bambas (:mayhemer)]

Closing since there is currently no motivation to have any decent production quality support for scriptable raw TCP servers in Gecko that should be anyhow customizable.  We have WebRTC now.