[SWMP] Re: faster field messages

["Jay C. Weber" <[e-mail]>]

[e-mail] wrote:

I think I understand the mechanism and I understand that either side of the pairwise communication can establish the mapping of an ID to a <node,field>.

Yes but as I defined it that mapping only applies in that one direction of the communication.  E.g., element A tells element B that "I will use the id '2' to represent the pair <node12,positionfield>", which constrains the meaning of future messages from A, but does not say anything about what field ids B will use in messages to A.

Perhaps it is a small thing, but in a situation in which one network element (say a server) manages the data, it would be helpful if it could use the same ID for all the other network elements seeking to use the data.  If the other network elements may establish the mapping, then it must keep independent mappings for each network element being served.  If, on the other hand, we can contrive the protocol, so that the network element managing the data establishes the ID mapping, then it could use the same mapping for all network elements seeking service.

The server in my current client/server architecture (and implementation) does already use the same ID mapping for messages to all its clients, possible because of this unidirectionality of field ids.  This is indeed very convenient when blasting out an update to all the clients, not having to customize field ids for each message.  (and this is really important for an architecture that uses multicast.)

But you are right that my server maintains independent mappings for each inbound message queue.  This requires some bookkeeping but is not complicated, and it is not any more space inefficient in the typical case where the clients are frequently changing distinct sets of nodes and their fields -- e.g., where each client controls his/her avatar and not others'.

The main advantages of this fieldid-definition-unidirectionality are that it avoids architectural limitations (baking in a master-slave relationship of fieldid-definition wouldn't be appropriate, say, for a peer-to-peer architecture), race conditions (peers racing to be the first to define a fieldid), or a centralized fieldid-definition service (which involves race conditions and either architectural limitations or a potential bottleneck).

jay

_______________________________________________
SWMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/swmp