Using patterned Topics to distinguish clients / allow 1:1 communication

#1

Hi

I am making more and more steps with using WAMP, Autobahn and Crossbar.io Router in my particular Application. One of the requirements of this Application is to distinguish individual clients from other and allowing 1:1 communications.

To make this possible I came up with the idea of using the topics to address clients / connected sessions. After some prototyping I found a topic pattern that best works for my application. Here it is:

de.myapplication.customer-id.device-type-id.device-id.command

Let me give you some details on each of the patterns parts:

de.myapplication

This is the reversed domain name style like advised in the documentation. So nothing special.

.customer-id

My Application has customers. Each customer should be addressable so I came up with assigning a UUID for each customer and make this ID part of the Topic-String.

.device-type-id

The Customers of my Application can create Device-Types with user defined names, commands, properties, etc. Each Type has an UUID and this ID is part of the Topic-String. With this information embedded into the Topic I can separate and authorize different Device-Types from each other, allowing Sub-Application listen to types of devices only.

.device-id

A newly connected device is using a Device-Type-Token or ID to submit its type. A new device is being registered and again an UUID is created. This ID addresses the unique device of given type and customer. This way I can address single devices and allow 1:1 communications.

.command

Everything before .command can be seen as some kind of prefix to the actual command / topic which is only used for addressing / distinguishing of the devices. The command can be something like Status, Message, Start, Stop and can lead to RPCs / subscription, etc.

In a real life example the above pattern would lead to the following topic:

de.myapplication.28db902a-08b0-4523-b117-6569780eca0d.b60ef06e-3579-4dd7-82be-ee0edae4baac.8eb781fe-8a02-4563-a129-ee7cb347ae4b.status

Starting with the reversed domain name, the topic can easily separated by customer, type and device + command. This way the WAM-Protocol is working like a charm for my particular application. I am however a bit afraid that topic is too long but I haven’ yet experienced any issues.

Anyway the fact that I can use dynamic authenticators, authorizers is such a good thing. I really begin to love the WAMP protocol and prefer it in so many ways.

I just wanted to share this with you and get some feedback on this.

Thanks,

Simon

0 Likes

#2

I think the key statement in your description is that it “best works for my application”, which I think makes it good indeed.

As for the length of the URI - if the primary purpose for including the customer ID is to allow for dynamic authorization, user information is already available to the dynamic authorizer in the session argument as session[‘authid’]. So you may be able to remove customer ID from your URI.

···

On Wednesday, August 31, 2016 at 7:15:45 AM UTC-7, Simon Kemper wrote:

Hi

I am making more and more steps with using WAMP, Autobahn and Crossbar.io Router in my particular Application. One of the requirements of this Application is to distinguish individual clients from other and allowing 1:1 communications.

To make this possible I came up with the idea of using the topics to address clients / connected sessions. After some prototyping I found a topic pattern that best works for my application. Here it is:

de.myapplication.customer-id.device-type-id.device-id.command

Let me give you some details on each of the patterns parts:

de.myapplication

This is the reversed domain name style like advised in the documentation. So nothing special.

.customer-id

My Application has customers. Each customer should be addressable so I came up with assigning a UUID for each customer and make this ID part of the Topic-String.

.device-type-id

The Customers of my Application can create Device-Types with user defined names, commands, properties, etc. Each Type has an UUID and this ID is part of the Topic-String. With this information embedded into the Topic I can separate and authorize different Device-Types from each other, allowing Sub-Application listen to types of devices only.

.device-id

A newly connected device is using a Device-Type-Token or ID to submit its type. A new device is being registered and again an UUID is created. This ID addresses the unique device of given type and customer. This way I can address single devices and allow 1:1 communications.

.command

Everything before .command can be seen as some kind of prefix to the actual command / topic which is only used for addressing / distinguishing of the devices. The command can be something like Status, Message, Start, Stop and can lead to RPCs / subscription, etc.

In a real life example the above pattern would lead to the following topic:

de.myapplication.28db902a-08b0-4523-b117-6569780eca0d.b60ef06e-3579-4dd7-82be-ee0edae4baac.8eb781fe-8a02-4563-a129-ee7cb347ae4b.status

Starting with the reversed domain name, the topic can easily separated by customer, type and device + command. This way the WAM-Protocol is working like a charm for my particular application. I am however a bit afraid that topic is too long but I haven’ yet experienced any issues.

Anyway the fact that I can use dynamic authenticators, authorizers is such a good thing. I really begin to love the WAMP protocol and prefer it in so many ways.

I just wanted to share this with you and get some feedback on this.

Thanks,

Simon

0 Likes

#3

Hi Steve,

thanks for your answer. I have to say that I have been working with some Publish / Subscribe systems before but WAMP is really working like a charm. In my application this pattern is needed. I cannot leave out the customer-id since I am using this in my application specific code. But that’s ok. I am not experiencing any issue with such long topic / uri strings.

···

On Thursday, September 1, 2016 at 6:47:14 PM UTC+2, Steve Ditlinger wrote:

I think the key statement in your description is that it “best works for my application”, which I think makes it good indeed.

As for the length of the URI - if the primary purpose for including the customer ID is to allow for dynamic authorization, user information is already available to the dynamic authorizer in the session argument as session[‘authid’]. So you may be able to remove customer ID from your URI.

On Wednesday, August 31, 2016 at 7:15:45 AM UTC-7, Simon Kemper wrote:

Hi

I am making more and more steps with using WAMP, Autobahn and Crossbar.io Router in my particular Application. One of the requirements of this Application is to distinguish individual clients from other and allowing 1:1 communications.

To make this possible I came up with the idea of using the topics to address clients / connected sessions. After some prototyping I found a topic pattern that best works for my application. Here it is:

de.myapplication.customer-id.device-type-id.device-id.command

Let me give you some details on each of the patterns parts:

de.myapplication

This is the reversed domain name style like advised in the documentation. So nothing special.

.customer-id

My Application has customers. Each customer should be addressable so I came up with assigning a UUID for each customer and make this ID part of the Topic-String.

.device-type-id

The Customers of my Application can create Device-Types with user defined names, commands, properties, etc. Each Type has an UUID and this ID is part of the Topic-String. With this information embedded into the Topic I can separate and authorize different Device-Types from each other, allowing Sub-Application listen to types of devices only.

.device-id

A newly connected device is using a Device-Type-Token or ID to submit its type. A new device is being registered and again an UUID is created. This ID addresses the unique device of given type and customer. This way I can address single devices and allow 1:1 communications.

.command

Everything before .command can be seen as some kind of prefix to the actual command / topic which is only used for addressing / distinguishing of the devices. The command can be something like Status, Message, Start, Stop and can lead to RPCs / subscription, etc.

In a real life example the above pattern would lead to the following topic:

de.myapplication.28db902a-08b0-4523-b117-6569780eca0d.b60ef06e-3579-4dd7-82be-ee0edae4baac.8eb781fe-8a02-4563-a129-ee7cb347ae4b.status

Starting with the reversed domain name, the topic can easily separated by customer, type and device + command. This way the WAM-Protocol is working like a charm for my particular application. I am however a bit afraid that topic is too long but I haven’ yet experienced any issues.

Anyway the fact that I can use dynamic authenticators, authorizers is such a good thing. I really begin to love the WAMP protocol and prefer it in so many ways.

I just wanted to share this with you and get some feedback on this.

Thanks,

Simon

0 Likes

#4

Hi Simon,

it’s great to hear that you like WAMP;)

Rgd URI design: you might also use something like this

de.myapplication.customer..devicetype..device..command

That is “prefixing” the IDs with the kind of ID that follows. This gives some additional URI stability/extendability. At least, this is a pattern we often use.

Sidenote: for 1:1 communication with PubSub, you could also use exclude/eligible publish options - but this isn’t as flexible as above. It all depends on the concrete use case / requirements …

Cheers,
/Tobias

···

Am Donnerstag, 1. September 2016 20:29:36 UTC+2 schrieb Simon Kemper:

Hi Steve,

thanks for your answer. I have to say that I have been working with some Publish / Subscribe systems before but WAMP is really working like a charm. In my application this pattern is needed. I cannot leave out the customer-id since I am using this in my application specific code. But that’s ok. I am not experiencing any issue with such long topic / uri strings.

On Thursday, September 1, 2016 at 6:47:14 PM UTC+2, Steve Ditlinger wrote:

I think the key statement in your description is that it “best works for my application”, which I think makes it good indeed.

As for the length of the URI - if the primary purpose for including the customer ID is to allow for dynamic authorization, user information is already available to the dynamic authorizer in the session argument as session[‘authid’]. So you may be able to remove customer ID from your URI.

On Wednesday, August 31, 2016 at 7:15:45 AM UTC-7, Simon Kemper wrote:

Hi

I am making more and more steps with using WAMP, Autobahn and Crossbar.io Router in my particular Application. One of the requirements of this Application is to distinguish individual clients from other and allowing 1:1 communications.

To make this possible I came up with the idea of using the topics to address clients / connected sessions. After some prototyping I found a topic pattern that best works for my application. Here it is:

de.myapplication.customer-id.device-type-id.device-id.command

Let me give you some details on each of the patterns parts:

de.myapplication

This is the reversed domain name style like advised in the documentation. So nothing special.

.customer-id

My Application has customers. Each customer should be addressable so I came up with assigning a UUID for each customer and make this ID part of the Topic-String.

.device-type-id

The Customers of my Application can create Device-Types with user defined names, commands, properties, etc. Each Type has an UUID and this ID is part of the Topic-String. With this information embedded into the Topic I can separate and authorize different Device-Types from each other, allowing Sub-Application listen to types of devices only.

.device-id

A newly connected device is using a Device-Type-Token or ID to submit its type. A new device is being registered and again an UUID is created. This ID addresses the unique device of given type and customer. This way I can address single devices and allow 1:1 communications.

.command

Everything before .command can be seen as some kind of prefix to the actual command / topic which is only used for addressing / distinguishing of the devices. The command can be something like Status, Message, Start, Stop and can lead to RPCs / subscription, etc.

In a real life example the above pattern would lead to the following topic:

de.myapplication.28db902a-08b0-4523-b117-6569780eca0d.b60ef06e-3579-4dd7-82be-ee0edae4baac.8eb781fe-8a02-4563-a129-ee7cb347ae4b.status

Starting with the reversed domain name, the topic can easily separated by customer, type and device + command. This way the WAM-Protocol is working like a charm for my particular application. I am however a bit afraid that topic is too long but I haven’ yet experienced any issues.

Anyway the fact that I can use dynamic authenticators, authorizers is such a good thing. I really begin to love the WAMP protocol and prefer it in so many ways.

I just wanted to share this with you and get some feedback on this.

Thanks,

Simon

0 Likes