User Tools

Site Tools


doc:rfc_kadaver

Kadaver - Remote Dongle Connectivity

OOBD Team S. Koehler
Request for Comments:17
Obsoletes: -
Category: Draft Standard Nov 2014

Status of this Memo

This memo provides information about how to implement a Websocket based communication between two devices as “extension” of the serial connection between an OOBD app and a dongle. Distribution of this memo is unlimited.

Copyright (C) OOBD Team (2014). All Rights Reserved.

Introduction

The Name Kadaver comes from the german wording “Kabellose Daten- Verbindung” (Wireless Data Connection). It connects a OOBD app with a Dongle over the internet and let them talk to each other with a chat server in between

Concept

The connection from the App (called “Master”) and from the dongle (“Slave”) is made by Websocket connections (from now on simply called “the connection”). Both sides connect them self to that server, and the server then sends the communication back and forward.

The slave only provides the connection, so it shall be as simple as possible to be easily used by novice.

Data model

Both master and slave sending JSON messages to the server. The messages contain two properties:

  • msg (Master) / receive (Slave): This is the text send to/from the dongle, coded in base64 (String)
  • channel: The name of the channel with master and slave are both using (String)

Initialization

The communication is initiated by the slave. The slave defines a name for the channel to use. This name can be random or e.g. the name of the Dongle, but it need to be unique for the time of the communication.

The slave then sends the above mentioned message to the server with this new channel name in channel and any value in reply. When reading the channel name out of the received JSON message, the Server assigns the channel to that websocket link.

Then the master needs to be informed about the channel name.

When then the master send it first message with that channel in channel and the dongle command in msg, then two things happen:

  • the server assigns the channel name to the websocket link of the master
  • the server then forwards the JSON message to the other clients with the same channel name (the slave)

Communication

After initialize the connection path, it's simple: Every message, which comes from one side is forwarded to the other and vice versa, identified by the channel name.

UI Requirements

As this connectivity might be implemented on different platforms, the following requirements shall be seen to be mandatory to have a common look & feel and functionality

Master (App Side)

  1. the Websocket Server URL shall be configurable and saveable in the settings
  2. The user shall decide when doing the connection if he wants to do a local or remote connection
  3. When doing the remote connection, he shall be able to enter the channel (which comes, as said, from the slave)

Slave (Dongle Side)

<graphviz dot> digraph finite_state_machine {

node [shape = box];
      n3  [ label = "(1)\nConnect to Webserver" ];
      n4  [ label = "(1a)\nDisplay Server settings\nfor correction & Retry" ];
      n5  [ label = "(2)\nCheck Bluetooth\nSocket Availability" ];
      n6  [ label = "(2a)\nInform User & Retry" ];
      n7  [ label = "(3)\nDo Bluetooth\nDongle Discovery\nNr. of Dongles found" ];
      n9  [ label = "(3a)\nInform User & Retry" ];
      n11 [ label = "(3b)\nDongle selection & Retry" ];
      n12 [ label = "(4)\nParing Dongle" ];
      n13  [ label = "(4a)\nInform User & Retry" ];
      n15  [ label = "(5)\nDisplay Channel\nNormal Operation" ];
      n16  [ label = "(99)\nEnd (Close Window)" ];
      n3 -> n4   [ label = "Error"  ];
      n3 -> n5   [ label = "Ok" color ="green" ];
      n4 -> n3   [ label = "Retry" ];
      n4 -> n16  [ label = "End" ];
      
      n5 -> n6   [ label = "Error" ];
      n5 -> n7   [ label = "Ok" color ="green" ];
      n6 -> n5   [ label = "Retry" ];
      n6 -> n16  [ label = "End" ];
      n7 -> n9 [ label = "0" ];
      
      n9 -> n7   [ label = "Retry" ];
      n9 -> n16  [ label = "End" ];
     
      n7 -> n11   [ label = ">1" ];
      n7 -> n12   [ label = "1" color ="green" ];
      n11 -> n12   [ label = "Pair" ];
      n11 -> n16  [ label = "End" ];
      n12 -> n13   [ label = "Error" ];
      n12 -> n15   [ label = "Ok" color ="green" ];
      n13 -> n12   [ label = "Retry" ];
      n13 -> n16  [ label = "End" ];
      
 

        n20  [ label = "User Settings" ];
        n21  [ label = "Webserver URL" ];
        n22  [ label = "Language" ];
   n20 -> n21 ; n20 -> n22 ;

} </graphviz>

Errors

FIXME to be defined

Implementation Details

Security Considerations

This RFC raises potential security issues. It's need to make sure that no issues can happen when somebody hijacks the data link

References

Authors' Addresses

Steffen Koehler

Phone: +49 172 410 35 98

EMail:steffen@koehlers.de

Appendix

Copyright (C) OOBD Team (2012). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the OOBD Team organizations, except as needed for the purpose of developing standards in which case the procedures for copyrights defined in the Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the OOBD Team or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE OOBD TEAM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.“ Relation to other RFCs

Updates

Obsoletes

Obsoleted-by

Updated-by

Contact

Distribution Lists

The OOBD-RFC announcements are distributed via the oobd-commit-messages@googlegroups.com mailing list.

To join (or quit) the list goto https://groups.google.com/forum/?hl=de&fromgroups=#!forum/oobd-commit-messages

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
doc/rfc_kadaver.txt · Last modified: 2014/11/27 19:05 by admin