Create mode service for the daemon and enable UDP channel in service mode

fmikulu commented 7 years ago

Imported from: https://iqrfsdk.atlassian.net/browse/SDKST-30?filter=-1 Can you describe required feature?

spinarr commented 7 years ago

Since UDP channel goes directly to SPI or CDC interface other channels must be disabled at that time. It is advised to introduce different modes in which daemon operates. E.g.

operational (UDP channel is dissabled, MQ and MQTT enabled)
service (UDP channel is enabled, MQ and MQTT dissabled - we have IDE IQMesh Network Manager in mind as a servise tool via UDP - bonding/unbonding/uploading/backup)
forwarding (all trafic from MQ or/and MQTT is forwarded to UDP port - IDE can be used for packet analysis)

Switching among modes may be done via iqrf json config commands - yet to be specified.

message category (ctype) : config message type (type) : configReq

{
  "config": {
    "mid": 1,
    "configReq": {
           "mode":"service",
           "...": ""
        } 
    }
}

fmikulu commented 7 years ago

What about to specify operational mode in this way (as used to be before exclusive access implementation)?:

operational (UDP channel runs in parallel with MQ and MQTT)

The switching among modes could be done as proposed. On the other hand wouldn't be better to switch it directly from IDE? There are periodic messages sent from IDE "GET_GW_STATUS" so just a simple flag added to the message would do the job easily. Another possibility is to implement "command line" via iqrfapp. It would be possible to send commands to running daemon, but only locally (from local cmd).

fmikulu commented 7 years ago

Proposed configuration:

{
  "RemotePort": 55000,
  "LocalPort": 55300,
  "Mode": "service",
  "ServiceTimeoutMillis": 30000
}

Mode operational || service || forwarding ServiceTimeoutMillis timeout to switch back to operational from service

Now the UdpMessaging implementation switches automatically to the service immediately when a traffic is detected from the IDE. It stays in the service up to the timeout elapsing. This feature may be removed as soon as the configuration switching will be done according one of the proposals.

spinarr commented 7 years ago

message category (ctype) : config message type (type) : configReq

can be also issued via mq channel - e.g. via iqrfapp locally

spinarr commented 7 years ago

One more clarification:

IQRF IDE is not sending "GET_GW_STATUS" all the time. There are states in IQRF IDE when this packet is not sent.

fmikulu commented 7 years ago

Lets review the proposal.

Modes:

operational UDP, MQ, MQTT, ... works in parallel, UDP is an ordinary source of DPA requests as the others
service UDP channel has the exclusive access, MQ, MQTT, ... dissabled - we have IDE IQMesh Network Manager in mind as a service tool via UDP - bonding/unbonding/uploading/backup
forwarding all trafic from MQ, MQTT, ... is forwarded to UDP - IDE can be used for packet analysis. This includes even DpaRequests issued from other channels or the Scheduler.

Modalities to switch:

Dedicated cmdl via iqrfapp/MqMessaging, just to keep it simple, e.g. > iqrfapp mode service. It is number one for implementation as it seem the easiest, next one will be implemented later according requirements and priorities
Json msg via MqttMessagin: {config: {confiqReq ... }}
Json msg via MqMessaging {config: {confiqReq ... }}
Special command from IDE - optionaly supported by IDE in future

Existing implementation to switch on/off automatically according running traffic over UDP, monitored by a watch dog will be replaced by the "Modalities to switch" proposal. The implementation will allow UDP to be easily replaceable in its service/forwarding role by other messaging components. In this way the IDE can use different methods of messaging or any other service tool could be used in future.

spinarr commented 7 years ago

ok

fmikulu commented 7 years ago

The modes Operational, Service, Forwarding are implemented as proposed. Switching is still TBD. However first tests shows that forwarded messages presentation in the IDE Terminal Log Window is questionable. See in table bellow lines 4, 7:

Line 1 - 3 is DpaRequest to node 1 sent directly from IDE Line 4 - 6 is DpaRequest to node 1 forwarded to IDE Line 7 - 8 is DpaRequest to coordinator (node 0) forwarded to IDE Line 4 - 6 is DpaRequest to coordinator (node 0) sent directly from IDE

It seems the IDE would be aware about forwarding mode and present forwarded Requests in a different way.

Line	Time	Rx/Tx	Length	DataHex	DPA
1	10:14:13.755	Tx	6	01.00.0A.00.FF.FF.	Request
2	10:14:13.849	Rx	11	01.00.0A.00.FF.FF.FF.68.00.03.00.	Confirmation
3	10:14:13.922	Rx	11	01.00.0A.80.00.00.00.69.15.51.01.	Response
4	10:17:40.092	Rx	6	01.00.0A.00.FF.FF.	Asynchronous
5	10:17:40.147	Rx	11	01.00.0A.00.FF.FF.FF.68.00.03.00.	Confirmation
6	10:17:40.220	Rx	11	01.00.0A.80.00.00.00.68.16.68.01.	Response
7	10:20:00.073	Rx	6	00.00.0A.00.FF.FF.	Notification
8	10:20:00.128	Rx	11	00.00.0A.80.00.00.00.68.1A.A0.01.	Response
9	10:20:03.959	Tx	6	00.00.0A.00.FF.FF.	Request
10	10:20:04.016	Rx	11	00.00.0A.80.00.00.00.68.1A.A0.01.	Response

fmikulu commented 7 years ago

Implemented Mode switch by iqrfapp:

>> conf Forwarding
>> conf Service
>> conf Operational

Other modalities will be implemented in scope of #5

spinarr commented 7 years ago

Suggestion before closing the issue:

do not leave udp channel enabled by default in operational mode (it is not fully functional since we are not able to set timeout for dpa messages)

fmikulu commented 7 years ago

Udp channel disabled in operational mode 361463815d8f5f13a1744a9147a47423e8e2b86d

iqrfsdk / iqrf-daemon

Create mode service for the daemon and enable UDP channel in service mode #8