[b2g] Network API: Gonk backend

NEW
Unassigned

Status

()

Core
DOM: Device Interfaces
5 years ago
4 years ago

People

(Reporter: jaoo, Unassigned)

Tracking

({dev-doc-needed})

Trunk
ARM
All
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:-)

Details

Attachments

(2 obsolete attachments)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
(Reporter)

Updated

5 years ago
OS: Mac OS X → All
Hardware: x86 → ARM
(Reporter)

Comment 1

5 years ago
We would need to implement something similar to Android ConnectivityService -NetworkManager- within Gonk backend.
This bug covers the central component that manages open connections and chooses between them.  We had tentatively decided not to make this a public interface, but rather keep it internal to gecko and let content control it through settings.  That seems reasonable to me.

We can implement for gonk first since that's the most interesting test case.

Comment 3

5 years ago
There are some requirements for NetworkManager, I think.
 - Support activating multiple links in any instant.
   - MMS and 3G data networking (Internet) usually use different APNs.
     It is a necessary to enable them simultaneously.
 - Define default route by user (upper layers)
 - Prioritize NICs to decide a DEFAULT default route automatically.
 - Tethering (?)
(Reporter)

Comment 4

5 years ago
After a quick view of ConnectivityManager and ConnectivityService from Android ferjm and I have defined a WebIDL interface for network manager. I am afraid we are not familiar enough with WebIDL interface definitions so let me say sorry if you find any error. I am not sure if it lacks any of the requirements mentioned by Thinker.

Thoughts?

#include "nsISupports.idl"


[scriptable, builtinclass, uuid(81840e80-3067-11e1-9699-0010183a41af)]
interface nsINetworkInfo : nsISupports
{

  const long NETWORK_STATE_UNKNOWN = -1;
  const long NETWORK_STATE_CONNECTING = 0;
  const long NETWORK_STATE_CONNECTED = 1;
  const long NETWORK_STATE_SUSPENDED = 2;
  const long NETWORK_STATE_DISCONNECTING = 3;
  const long NETWORK_STATE_DISCONNECTED = 4;

  /**
   * Network state. Must be one of the NETWORK_STATE_* constants. 
   */
  attribute long networkState;

  const long NETWORK_TYPE_MOBILE      = 0;
  const long NETWORK_TYPE_WIFI        = 1;

  /**
   * Network type (e.g., WIFI). Must be one of NETWORK_TYPE_* contanst.
   */
  attribute long networkType;

  /**
   * Indicates whether network connectivity is possible.
   */
  attribute boolean isAvailable;
}


/**
 * It keeps track of the state of connectivity of a network interface. 
 * It manages the network-type-independent aspects of network state.
 */
[scriptable, builtinclass, uuid(e016d594-3072-11e1-9b7d-0010183a41af)]
interface nsINetworkState: nsISupports
{
  /**
   * Describes the status of a network interface of a given type
   * (currently either Mobile or Wifi).
   */
  attribute nsINetworkInfo networkInfo;
  
  attribute DOMString interfaceName;

  /**
   * List of system property names containing DNS server addresses for this
   * network connection.
   */
  attribute DOMString[] dnsPropName;

  attribute long defaultGatewayAddr;

}

[scriptable, builtinclass, uuid(f13e5f84-3092-11e1-a06d-0010183a41af)]
interface nsINetworkManagerCallback : nsISupports
{
  void onactivenetworkchange(in jsval event);

};

[scriptable, builtinclass, uuid(3bc29392-2fba-11e1-80fd-0010183a41af)]
interface nsINetworkManager : nsISupports
{
  //XXX Is this correct?
  const long DEFAULT_NETWORK_PREFERENCE = nsINetworkInfo::NETWORK_TYPE_WIFI;

  /**
   * Prefered network type.
   */
  attribute long preferedNetworkType;

  /**
   * Mobile data enabled?
   */
  attribute boolean mobileDataEnabled;

  /**
   * Returns NetworkInfo for the active (i.e., connected) network interface.
   */
  nsINetworkInfo getActiveNetworkInfo(); 
  nsINetworkInfo[] getAllNetworkInfo();

  /**
   * Sets the network interface as active. 
   */
  void setActiveNetwork(in nsINetworkInfo networkInfo);

  /**
   * Disables the network interface. 
   */
  void disableNetwork(in nsINetworkInfo networkInfo);

  void registerCallback(in nsINetworkManagerCallback callback);
  void unregisterCallback(in nsINetworkManagerCallback callback);
};
Component: General → DOM: Device Interfaces

Comment 5

5 years ago
(In reply to jaoo from comment #4)
>   const long NETWORK_TYPE_MOBILE      = 0;
This type should be divided into sub-types for various purposes.
We need at least Internet and MMS.

>   nsINetworkInfo getActiveNetworkInfo(); 
It is necessary to enable more than one link.  So, this method should return an array.

>   /**
>    * Sets the network interface as active. 
>    */
>   void setActiveNetwork(in nsINetworkInfo networkInfo);
Rename to activateNetwork(...) for supporting multiple link?

> 
>   /**
>    * Disables the network interface. 
>    */
>   void disableNetwork(in nsINetworkInfo networkInfo);
Rename to deactivateNetwork(...) ?

We still need to add APIs that users (upper layers) can set the default route and
routes for given hosts.  For exampe, we need a route for the MMS server
to forward MMS messages through a separated PDP interface (different APN).
(Reporter)

Comment 6

5 years ago
At https://github.com/jaoo/mozilla-central/blob/networkmanager/dom/system/b2g/nsINetworkManager.idl lives a new version of the network manager interface. I think all problems previously mentioned have been solved. Thoughts?.

Comment 7

5 years ago
jaoo had mentioned 

   * XXX: Wouldn´t it be better to activate it by using the network interface
   * name, as it is the only unique parameter. It is possible to have more
   * than one network with the same type (i.e. usb 3G dongle)

It is a good idea.  If we want to use network interface name, requestRouteToHost() should be changed too.

  /**
   * List of system property names containing DNS server addresses for this
   * network connection.
   */
  attribute DOMString[] dnsPropName;

For Android 3.0+, rild returned DNS server addresses directly.  Property name is too platform and implementation dependents.  I suggest to use DNS addresses.  Let implementations figure out how to retrieve addresses from system.

Comment 8

5 years ago
Created attachment 585125 [details] [diff] [review]
-

Updated

5 years ago
Attachment #585125 - Attachment is obsolete: true

Comment 9

5 years ago
Created attachment 585126 [details] [diff] [review]
Network interface
(In reply to Thinker Li from comment #9)
> Created attachment 585126 [details] [diff] [review]
> Network interface

This interface defines functions and attributes of NIC backends.
NetworkManager use this interface to control NICs of various network technologies.
I have tried to do a simple implementation of purposed interfaces.  I found something.
 - The network manager must call functions of network interfaces in asynchronized to avoid blocking from backends.
 - Is it a good idea to use long type for host addresses?  Maybe dotted string is better.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Depends on: 713426
Depends on: 712629
Comment on attachment 585126 [details] [diff] [review]
Network interface

The network DOM API will be very, very limited. This code seems more like something for bug 697355, though that's also a DOM API. The API you're proposing here is very low-level and doesn't even need to be exposed to content. In fact, does stuff like setting routes even need to be available as an API? Wouldn't it be enough to have an API for switching between certain interfaces?
Depends on: 717122
(In reply to Philipp von Weitershausen [:philikon] from comment #12)
> Comment on attachment 585126 [details] [diff] [review]
> Network interface
> 
> The network DOM API will be very, very limited. This code seems more like
> something for bug 697355, though that's also a DOM API.

Filed bug 717122 for the Gecko component that will power the network and network manager APIs.
Attachment #585126 - Attachment is obsolete: true
blocking-basecamp: --- → ?
We haven't really implemented any kind of Network API. Enabling/disabling things is happening through settings, and the Wifi and MobileConnection APIs should expose enough information for UI -- for now at least. Unless I'm missing something?
The idea behind this bug was to implement what philikon did in bug 717122. Moreover we manage to switch between interfaces through the setting API. According to [1] I guess we should flag this bug as WONTFIX or WORKSFORME, am I right? . I am sorry If I did not explain myself in comment #1. 

[1] https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla
Isn't this bug specifically about implementing a gonk backend for the API implemented in bug 677166?

Comment 17

5 years ago
Not mandatory at WebAPI level, Jonas is filing a bug for system level support in order to support bug 737601.
blocking-basecamp: ? → -
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.