search

opengeospatial / sensorthings

The official web site of the OGC SensorThings API standard specification.
136 stars 29 forks source link

MQTT create observation issues #5

Open mjacoby opened 8 years ago

mjacoby commented 8 years ago

As for creating an observation via MQTT and subscribing to new/changed observations the same MQTT topic can be used (v1.0/Observations) all requests to create a observation from one client to the server are received by all other clients watching the observations entity set. Personally, I find this quite ugly as now each client subscribing to changes will also receive requests from other clients to the serve to create observations on the same topic and has to do some content checking (e.g. check if the payload does not contain an @iot.id than it is a observation create request) to distinguish what is really a change and what is a request from another client to the server which I'm not interested in.

Are you aware of this issue and is this design on purpose? Have you though about any nicer way to handle this while writing the standard?

Furthermore, there is no feedback from the server to a client requesting the creation of an observation via MQTT. Is this also on purpose?

liangsteve commented 8 years ago

Yes. It has been discussed in the SWG meetings. Different ways have been proposed, discussed, and analyzed. At the end, the current way is adopted. There are always pros and cons. The good thing about current way is that the pattern of HTTP POST and MQTT is the same. No confusion there. There should be more design rationales for this decision. Anyone can help out Michael?

Regarding the question of no responses from server after MQTT create, MQTT is a light-weight protocol. It is not like HTTP. It doesn't have a response mechanism.

mjacoby commented 8 years ago

Thanks for the clarification. Having URLs/topics with the same name between HTTP and MQTT is of course nice but I think in this case the drawbacks outweigh this as MQTT clients will receive messages they neither want to receive nor expect to receive and they must filter these message out. Furthermore, it is not explicitly stated in the standard that this is a known issue and should be taken care of when subscribing to observations via MQTT.

I personally could image another MQTT topic structure something like this

Subscribe to entity sets

Subscribe to entity

Subscribe to property

Subscribe to entity set with select Just like subscription to entity set but with additional ?$select=property1,...,propertyN after the entity set name

Creating observations

This also addresses the issue of providing feedback on the success/failure of an observation create request via MQTT by introducing an extra topic only for feedback.

As the standard is now officially published in version 1.0 this can be seen as input for discussion on future versions.

hylkevds commented 5 years ago

Finally had a quick look at the MQTT v5.0 overview, and one new thing that would be perfect for this issue is:

User properties: Add User Properties to most packets. User properties on PUBLISH are included with the message and are defined by the Client applications. The user properties on PUBLISH and Will Properties are forwarded by the Server to the receiver of the message. User properties on the CONNECT, SUBSCRIBE, and UNSUBSCRIBE packets are defined by the Server implementation. The user properties on CONNACK PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK and AUTH packets are defined by the sender, and are unique to the sender implementation. The meaning of user properties is not defined by MQTT.

If we add support for MQTT v5, we could put the type of change (create, update, delete) in such a user property. That means we don't need separate topics for create/update/delete, unless we specifically want to be able to only receive create messages. Right now I can't think of a use-case where one would want create, but not update/delete messages.

Request / Response: Formalize the request/response pattern within MQTT and provide the Response Topic and Correlation Data properties to allow response messages to be routed back to the publisher of a request. Also, add the ability for the Client to get configuration information from the Server about how to construct the response topics.

This means we can respond to create messages, with either an error or success code. We could even completely mimic the HTTP interface, by setting the HTTP Method as a user property, and answering with a response.

The issue of double-messages does not seem to be solved by MQTT v5. So we might still want to keep the "/request" topic postfix for sending messages to the server.

Quick overview of 3.1.1 vs 5.0: https://github.com/mqtt/mqtt.github.io/wiki/Differences-between-3.1.1-and-5.0