MEEP (JSR-361 EDR Draft)

Package javax.microedition.io

[OPTIONAL] Networking support based on the Generic Connection Framework Specification.

See: Description

Package javax.microedition.io Description

[OPTIONAL] Networking support based on the Generic Connection Framework Specification.

Description

The Generic Connection Framework (GCF) is the base for the extended functions: Unless otherwise noted, passing a null argument to a constructor or method an any class or interface in this package MUST cause a NullPointerException to be thrown.

IPV4 and IPV6 Support

The attribute MIDlet-Required-IP-Versiondetermines that the implementation MUST use the specified IP version in all the network connections. The implementation MUST NOT allow an application to make connections to ports that have been dedicated to different IP version usage than what the application is requiring. If the implementation cannot provide the application with the required IP version at runtime, an java.io.IOException MUST be thrown.

Inter-IMlet Communications using IMC

The MIDP Inter-MIDlet Communication protocol defines a low-level, asynchronous, bi-directional stream connection to support direct communication links between applications. IMC is provided by IMCConnection and IMCServerConnection.

Very similar to the socket protocol, the IMC protocol provides for both client and server connection. When an IMC client makes a connection to a server, the IMC server is identified by application UID, and the IMC server name and version. The application UID is the unique identifier of an application, composed of the combination of the application's name, vendor, and version. The application UID is omitted in the connection URL strings when opening an IMC server connection.

The Inter-MIDlet Communication protocol (IMC) MUST be supported by all implementations that include this javax.microedition.io LIBlets enable applications to share software components; however, an application and the LIBlets it depends upon are statically bound at installation into a single isolated runtime execution environment. Further, code belonging to a single LIBlet and bound to multiple application's execution environments cannot easily exchange data at runtime.

With the introduction of Inter-IMlet communication, an application will be able to access a shareable component running inside another execution environment through thin client APIs, and thus make possible component based programming for applications. The shareable component runs inside another application execution environment and handles requests from other applications.

An example use case for Inter-application communication is a sensor data collector. In this use case, an application controlling a technical facility based on incoming sensor data invokes sensor data collecting applications through an IMC connection in order to receive the collected and processed sensor data needed. These sensor data collecting applications are executed as if they were LIBlets bound to the Controller application, but can be individually installed or deleted and run inside isolated execution environments.

An application starting an IMC server can be launched in the background when the device is powered on, or at client request. Unlike LIBlet code static sharing, an application's IMC server can be independently shut down and unloaded from memory if it is no longer serving client requests. An IMC server can use all of the APIs available to an applications including, when appropriate and available, interactions with the network or user.

Push Applications

The PushRegistry is available to provide an application with a means to register for network connection events, which are delivered to the application if it is running or start the application if it is not running and then deliver the network connection event. The security of PushRegistry is defined by the Auto-Invocation Security Policy.

The risks associated with an application application’s use of the network are related the potential for network abuse and to costs to the device owner since network use may result in charges. This specification provides a security framework in which network functions can be protected and allowed only to those applications that are bound to a Security Protection Domain containing the appropriate permissions.

QoS Related Connection Options for SocketConnection and ServerSocketConnection

In order to support Quality of Service (QoS) requirements, the implementation MUST extend the SocketConnection and ServerSocketConnection as defined in CLDC-8. The implementation of SocketConnection has to support the following additional settings for calls to Connector.open :

ConnectionOption Type Sample Value
sendingDelayVariation Integer 50
receivingDelayVariation Integer 50
sendingLatency Integer 100
receivingLatency Integer 100
sendingLevelOfGuarantee Integer impl. dependent
receivingLevelOfGuarantee Integer impl. dependent
sendingPeakBandWidth Integer 5242880
receivingPeanBandWidth Integer 5242880
sendingTokenBucketSize Integer 1048576
receivingTokenBucketSize Integer 1048576
sendingTokenRate Integer 4194304
receivingTokenRate Integer 4194304
sendingProviderSpecificQos Byte[] impl. dependent
receivingProviderSpecificQos Byte[] impl. dependent

sendingDelayVariation and receivingDelayVariation can be used to specify the tolerable jitter for data sending/receiving operations.

sendingLatency and receivingLatency can be used to specify the maximum acceptable delay between sending and receiving in microseconds for data sending/receiving operations.

sendingLevelOfGuarantee and receivingLevelOfGuarantee can be used to specify the desired QoS for data sending/receiving operations. Values for the level of guarantee are implementation dependent. Proposed and recommended value examples could be :

sendingPeakBandWidth and receivingPeakBandWidth can be used to specify the maximum bandwidth in bytes per second for data sending/receiving operations, which can be sent until the bucket is empty.

sendingTokenBucketSize and receivingTokenBucketSize can be used to specify (together with the token rate) the burstiness of the datastream for data sending/receiving operations.

sendingTokenRate and receivingTokenRate can be used to specify the average bytes per second to be sent for data sending/receiving operations.

sendingProviderSpecificQos and receivingProviderSpecificQos can be used to specify provider specific QoS parmaters for data sending/receiving operations. The possible values are implementation dependent.

The implementation of ServerSocketConnection has to be extended in a way that it accepts (or does not accept) the required QoS characteristics and negotiates the QoS related conditions with the socket side.

Example

The following example demonstrates how a socket connection can be opened via GCF and certain QoS requirements can be expressed :


 ConnectionOption <Integer> sendingLatency =
      new ConnectionOption<Integer>("sendingLatency", 200);
 ConnectionOption <Integer> receivingLatency =
      new ConnectionOption<Integer>("receivingLatency", 100);
 ConnectionOption <Integer> sendingTokenRate =
      new ConnectionOption<Integer>("sendingTokenRate", 4194304);
 ConnectionOption <Integer> receivingTokenRate =
      new ConnectionOption<Integer>("receivingTokenRate", 4194304);

 try {
      SocketConnection c = (SocketConnection)Connector.open(
          url, sendingLatency, receivingLatency,
          sendingTokenRate, receivingTokenRate);
 } catch (IOException e) {
      // ...
 }
  
Since:
IMP 1.0
MEEP (JSR-361 EDR Draft)
24-Mai-2013 05:26

Copyright (c) 2013, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.