Question about aspect filtering & dispatch

[ThomasFreedman]

I have a working request message handler system that dispatches incoming requests to an appropriate handler. A few bytes at the start of the data define a msgType to control this.

I suspect that is what the aspect filtering was designed to help with.

What I'm not sure of is how to use aspects to accomplish this. Is it simply a matter of registering multiple handlers with different "paths", or does it require different destinations, each with a unique aspect filter?

If that is the intended design pattern I failed to grasp it, hence why I used the single destination approach I did. I don't find it intuitive to think of destinations in that way. I see them as synonymous to entity, not function.

RNS is a new animal and I'm just getting familiar with it, so I'll admit the approach I've taken may not be optimal.

[markqvist]

I suspect that is what the aspect filtering was designed to help with.

No. Aspect filtering in the announce-handling mechanisms are there to allow your application to only receive announce notifications about the destination types it cares about.

A few bytes at the start of the data define a msgType to control this.

This is probably inefficient. You may want to just use different request paths to do this.

Also, remember that Reticulum can send and receive arbitrary data structures directly in Requests and Responses.

You don't have to do binary encoding yourself, and in almost all cases, it will be more efficient to let Reticulum handle this, since it takes into account optimal packing and compression, across the entire data stream.

You can do this:

request_data = {
    "cmd": "do_math",
    "operation": "sum",
    "numbers": [2, 3, 5, 7, 11]
}

established_link.request("/my_dynamic_handler", data=request_data, response_callback=my_callback) 

And your request handler in the other end will receive that exact data structure. No need to do any packing or unpacking yourself.

[ThomasFreedman]

That's very cool, I'll definitely keey that in mind as I incorporate Resources.

Regarding aspect filtering tho, you have just introduced another point of confusion for me. Aspects & request handler paths are unrelated?

[markqvist]

Yes, completely unrelated. They have nothing to do with each other.

Aspects let you create many different Destinations from the same Identity.

Request paths let you create many different request handlers for the same Destination.

[ThomasFreedman]

I previously wrote (in the discussion last week that described my app):

I thought I came up with a way to use the intended design pattern for destinations, but as I was debugging it I realized every destination requires a new link and / or new resources.

but after reading your statement:

Request paths let you create many different request handlers for the same Destination.

I took yet another look. I'm happy to report I finally get it now, and have used the path value to replace my msgType I was prefixing to the data payload of requests. Moving on to figure out if I can use RNS.Resources to get around the packet size limitation.

[markqvist]

If you use requests as intended, there are no limits imposed by "packet size". Requests can take arbitrary data sizes for both the requests and the responses.

[jonarmani]

I don't find it intuitive to think of destinations in that way. I see them as synonymous to entity, not function.

One of IP's fatal flaw was this mixup, known as the "loc/id split." An IP address is overloaded by both locating and identifying entities. RNS employs destinations as purposeful addresses an entity presents in a one-to-many relationship.

[markqvist]

Exactly.

And if you want some thing that ties many different destinations, you can create them all with the same Identity.

[ThomasFreedman]

I don't find it intuitive to think of destinations in that way. I see them as synonymous to entity, not function.

One of IP's fatal flaw was this mixup, known as the "loc/id split." An IP address is overloaded by both locating and identifying entities. RNS employs destinations as purposeful addresses an entity presents in a one-to-many relationship.

I agree 100%, but my statement was made about RNS Destinations before I fully realized how request paths worked. Mixing Destination Aspect filtering with Request dispatching using paths, I thought Destinations were tied to a specific app function.

Now I am seeing things more clearly, and realize Aspects are ONLY for announce targeting & filtering which is more of an identity thing (as in, what Destination is this announce targeting, not as in RNS.Identity), vs Request paths which is separate and relates to specific app functions.

In RNS there is no physical "location" concept. RNS is agnostic regarding that. Point of fact: a physical location based on IP isn't as rigid now as it was in early days. With DHCP and dynamic routing an IP address can float around in physical space as well, although it's far more restricted in IP that RNS.