|Re: [paho-dev] FW: MQTT Interop Testing Day|
It would be great to have your awesome community building capabilities to get more people attending the testing day. Feel free to go promote wherever. I do think we need to make sure we get a variety of MQTT clients. We seem to already have lots of brokers.
I thought I answered the first two before :-)
On 10/12/13 17:44, Andy Piper wrote:
Jumping back in to this conversation much later in the process.... *grin*
From the point-of-view of representing one of the existing broker implementations at the Interop Day, I'd like to clarify a few things, specifically:
- why bridge behaviour is included, since it is a) not part of the spec and b) has only been implemented outside of IBM through reverse engineering to understand the format -> wiki and mailing list clarification. I'd prefer to see this stick to the specification (as it exists by then, either 3.1, or OASIS 3.1.1 if out of draft)
The bridge behaviour is included only when acting as a normal MQTT client. After all, the "bridge protocol" is only two minor differences, and with RSMB, it drops back to MQTT v3 normal behaviour. With servers that do have a bridge, it's a good way to test interoperability.
- whether test code will be supplied ahead of time, and whether (if we are pairing client/server implementations) this will be in one specific language / use one client library
The goal is to have tests available in January. Server tests will be not using any particular client. Client tests will be abstract, so it's up to the implementer of the client library to create concrete versions of them for a particular client. Of course then the client tests can be run against any server.
- whether there is any more than 1 more call planned prior to EclipseCon to hammer out any additional details, and how we will be inviting other broker providers to participate.
No problem with more calls. All broker providers are invited whether they know it or not!
Also, whilst this is happening under the aegis of Eclipse / EclipseCon and Paho (and I guess now, the Mosquitto project too!) - it might be an idea if we actually had this set of conversations over on the Google Group to get wider visibility. We should also clarify the current contents of the "server support" page on the MQTT community wiki -> currently housed at https://github.com/mqtt/mqtt.github.io/wiki/server-support
Sure. Want to kick it off? I'm writing tests...
(the latter page is also probably a good starting point for identifying server implementations we'd like to see represented / we should contact directly, notwithstanding new additions like the D, Go and Erlang brokers I've recently learned about via https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/)
On Wed, Nov 6, 2013 at 5:36 PM, Ian Skerrett <ian.skerrett@xxxxxxxxxxx> wrote:
Here are the meeting minutes from this past Monday.
My plan is to post minutes on the wiki. It might take a couple of days to get them posted.
FWIW, I have started a new wiki page for the MQTT Interop Testing day. This will be where all the event information will be hosted.
From: paho-dev-bounces@xxxxxxxxxxx [mailto:paho-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Piper
Sent: November-04-13 5:55 PM
To: General development discussions for paho project
Subject: Re: [paho-dev] FW: MQTT Interop Testing Day
Having screwed up timezones I managed to dial in as you were all saying goodbye to one another... doh.
Minutes to go on wiki?
On Mon, Nov 4, 2013 at 2:44 PM, 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.
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:
- 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
_______________________________________________paho-dev mailing list
paho-dev mailing list
Back to the top