Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] FW: MQTT Interop Testing Day


1) Server to server can be pure MQTT v3, albeit with couple of minor niggles.  RSMB falls back to standard v3 if the other bridge connect fails. 

Other points noted. 

Ian



On 04/11/13 18:41, Paul Fremantle wrote:
A few thoughts:

1) Am I right in thinking that the server to server mode isn't documented in the spec and therefore I would assume fits into your categeory 9? 

2) My own experience of interop testing is that it helps a lot to have endpoints up on the internet before and after the face-to-face. Firstly - this obviously helps for people who can't attend the F2F, but also means that some ongoing testing can go on.

3) It helps even more if the other system (client and/or server) is easily run by whoever is testing their own implementation. So if I'm testing my implementation of a client and I can run all the servers easily and see the logs that helps a lot. Likewise if I can try out multiple clients easily. 

4) Access to the other side's logging is an incredibly useful thing.

Paul



On 4 November 2013 14:44, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
My starting point for a plan on the technical side of things, as input to the call.

1) We need tests for both MQTT client libraries and servers.  Servers may also act as clients connecting to other servers (called a bridge in Mosquitto/RSMB).

2) The MQTT OASIS specification is nearing a public consultation draft.  It will contain normative statements which will be listed, and the various degrees of compliance required categorized as in RFC 2119. 
"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC 2119."

3) I propose we take each of the listed normative statements and turn them into one or two test cases, with a link back to the specification.   Each statement will apply to either server or client library, some to both.  Each test case will test either client library or server and will consist of input sequences along with assertions about the results that should/must be observed.

4) Server tests can be described at the MQTT packet level.  I already have some tests which do this - so does Roger. Each of the server tests will be a sequence of MQTT flows into a server, interleaved with the expected MQTT packets out of the server.

5) Because the interfaces used to drive client libraries are all different, the client tests will need to be more abstract.  They could also be termed in MQTT packet flows, in this sort of way "make calls to the client library to cause MQTT packet flows foo", "following packet flow bar, make a message available to the application", and so forth.  Using these test scenarios, any client library can be tested against any server.

6) Server bridge tests will be similar to client tests - probably a subset as bridges have more limited scope for behaviour in general.

7) On the day, servers would be expected to be configured in a standard way to allow the client tests to work against them.  We'll publish that configuration as part of the client tests.

8) We will have at least one Mosquitto instance available for anyone to test against on the day.  We expect to have Mosquitto updated to allow OASIS conforming clients to connect.  

9) Other aspects, which may not be in the specification directly, that we might like tests for: SSL/TLS connections, High Availability client library support.  

Ian









On 04/11/13 08:38, Ian Skerrett wrote:

Just a reminder, we will be having a call later today to discuss the MQTT Interop Testing Day. If you are interested in helping out, please plan to attend or let me know.

 

Thanks

Ian

 

 

From: Ian Skerrett [mailto:ian.skerrett@xxxxxxxxxxx]
Sent: October-17-13 10:29 AM
To: m2m Industry Working Group (m2m-iwg@xxxxxxxxxxx); General development discussions for paho project (paho-dev@xxxxxxxxxxx)
Cc: Ian Craggs
Subject: MQTT Interop Testing Day

 

We are planning to organize an MQTT Interop Testing Day at EclipseCon NA. The intent is to have a daylong testing session on Monday March 17.

 

Ian Craggs has graciously volunteered to help lead the technical coordination of the day and I will help with the logistics.

 

At this time, we are looking for volunteers to help organize this event. We are planning to have a kick-off call on Monday, November 4 at 8amPT/11amET/17:00CET.  If you can’t make this time but would like to help, please let me know.

 

The conference call-in numbers will be:

 

Phone numbers

  • North America 1-866-569-4992
  • Germany 49-692-2224-6059
  • France 33-17-070-8535
  • UK 0800-033-7806
  • Switzerland 004-144-580-2115
  • Spain 34-900-804-766
  • Sweden 46-85-063-8386

Then enter the participant conference extension: 427, then enter pin 1156

Alternatively, SIP clients call 427@xxxxxxxxxxxxxxxxxxxx, then enter pin 1156

 

 

 

Regards,

Ian

 

 



_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev




--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top