Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008953opensim[GRID] Hypergridpublic2021-12-12 12:302021-12-15 07:37
Reporteraiaustin 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformLinuxOperating SystemLinuxOperating System VersionLinux
Product Version0.9.2.1Dev 
Target Version0.9.2.1DevFixed in Version 
Summary0008953: IMs and group messaging across the HG (report on behalf of gimisa.cerise @3d.gimisa.ca:9000)
Descriptiongimisa.cerise @3d.gimisa.ca:9000 has documented an issue with Instant Messages across the Hypergrid... and believes the issue is still present in 0.9.2.1 dev master as at 12th December 2021. He documented this previously at

http://opensimulator.org/wiki/User:Gimisa#IM [^]

gimisa.cerise @3d.gimisa.ca:9000: It took me about three days to figure out that robust what I call out service is failing to get notification from other grid routed to the region where the avatar is . An error occurs that give the NULL UUID instead of the region correct location . That is even if the database itself has the correct information.

----------

INSTANT MESSAGES (210715)
They are the backbone of social interaction in opensim alone with local chat and voice. This feature works very well in local grid where two avatar or an object to avatar communication is possible across the entire grid. HG INSTANT MESSAGE is the ability to communicate with other avatar across grid. The general spec of that initiative is given by DIVA in her 2011 blog ref : <http://www.metaverseink.com/blog/hypergrid/friends-and-im-over-the-hypergrid/>http://www.metaverseink.com/blog/hypergrid/friends-and-im-over-the-hypergrid/ [^] . In 2013 she released an addon that eventual got integrated in opensim core. This initiative was a success within DIVA distro but was never fully successful in core implementation.
The role of the secret key is explain by DIVA in the following terms:
"An HG friendship establishes 2 pairs of data, each stored in each user's user services. That data is "signed" with a random number known only to the 2 services and the simulator where the friendship was established, so that, even if the user services (hg friends, to be precise) are exposed to the Internet, no one but the holders of the signature can manipulate the friendship data".

The friend database include two entry. One is all friend to you. And the other is the opposite HG People friend to local grid users. That secret key stored in friend database is used to allow to be notified when you login/logout (and vice-versa), to change your objects (and vice-versa), to see you on the map (and vice-versa), etc. All services would be affected equaly if the secret key is the determining factor of the problem. But they are not . And this discrepancy in service rendering, online indication, IM delivery and so on is an indication that the trouble is a question of how each of this service works. What is puzzling is that ONLINE indication should be a simpler feature yet easy to make work properly. If we follow DIVA spec the intended action is that ONLINE status should follow the HG traveller in his quest. As long as he is traceable by his friend the HG friend should be shown online. IM messages and other friend service should be equally successful. At this current version 0901, the only reliable way to have contact with HG friend is to move along to their local grid to confirm online indication and establish contact.
I have extended the discussion with an example test and discussion to overcome the limitation of a user page graciously offered by opensimulator.org. See <http://profil.gimisa.ca/opensimCommunication.pdf>http://profil.gimisa.ca/opensimCommunication.pdf [^]
The above communication document is still valid with 0.9.2.* September 2018 release. But since a few months now has raised a busy exception to IMs sent by people replying to your IMs . I thought it was my configuration that needed updating and then started checking the source code activating debug messages. Finally I found that <https://mosthugs.win/>https://mosthugs.win/ [^] (Nani's Opensimulator version) had looked at the situation and found a cure that worked for me .

Additional InformationAi Austin is reporting this after a report verbally on 12th December 2021 by gimisa.cerise @3d.gimisa.ca:9000 to ensure the issue can be tracked. I have not verified the details or solution proposed myself.
TagsNo tags attached.
Git Revision or version number0.9.2.1 Dev Naster 12-Dec-2021
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script EngineYEngine
EnvironmentMono / Linux64
Mono VersionNone
ViewerAny
Attached Files

- Relationships

-  Notes
(0038291)
aiaustin (developer)
2021-12-12 12:32

Gimisa reports it MAY be a Linux issue as he does not see the problem in DreamGrid (which is Windows only)
(0038292)
JeffKelley (reporter)
2021-12-12 15:36
edited on: 2021-12-13 18:01

Confirming that both HG presence and messaging works erratically from a long time to the point that hypergriders take them for non-existent. Failed friendshiping is common, the admitted rule is that you sould offer friendship on one of the two avatars' home grid, the second (hypergrided) avatar then returning home to accept the friendship. Even so, presence and IM are not guaranteed to work, some grids appearing to handle them better, with no clear pattern (Windows vs. Linux, Flotsam vs. V2, standalone vs. grid)

(0038294)
gimisa (reporter)
2021-12-15 07:37
edited on: 2021-12-18 11:17

I agree Jeff. Its been a long time standing . But the latest I was discussing with Austin in regards to 092 was BUSY reply on instant message.

This late problem appear about last year. Checing log I notice that when LOCAL avatar log it send message to all grid where friends are located as it should.

Online presence is acknowledge by the REMOTE grids as it should. BUT and that is new ROBUST service show a null string in log as actual region the LOCAL avatar is . I tried so isolate the problem by separating 8003 port service calling it robustIN and port 8002 calling it robustOUT and the problem show up in log of robustOUT .

I try different things but what work was to take lani robust and create a new robustOUT ini to service port 8002 keeping opensim for 8003 port service. My subsequent testing confirmed that each time local avatar loc in the now NANI robustOUT was reporting properly the region location of the new rezing avatar region UUID to the request made by remote grids.

I have provided this discussion in opensim dev mailing list a few months ago without raising any interest so I supposed it was only occuring on LINUX version and left it as so. Yesterday I mention this to Austin which said it should be acknowledge anyway.

So here we are , thanks for you attention to this Jeff.


- Issue History
Date Modified Username Field Change
2021-12-12 12:30 aiaustin New Issue
2021-12-12 12:32 aiaustin Note Added: 0038291
2021-12-12 12:32 aiaustin Operating System Windows => Linux
2021-12-12 12:32 aiaustin Operating System Version 10 =>
2021-12-12 12:32 aiaustin Platform PC => Linux
2021-12-12 12:33 aiaustin Environment .NET / Windows64 => Mono / Linux64
2021-12-12 12:33 aiaustin Operating System Version => Linux
2021-12-12 12:34 aiaustin Summary IMs and group messaging across the HG => IMs and group messaging across the HG (report on behalf of gimisa.cerise @3d.gimisa.ca:9000)
2021-12-12 15:36 JeffKelley Note Added: 0038292
2021-12-13 18:01 JeffKelley Note Edited: 0038292 View Revisions
2021-12-15 07:37 gimisa Note Added: 0038294
2021-12-15 07:39 gimisa Note Edited: 0038294 View Revisions
2021-12-15 07:44 gimisa Note Edited: 0038294 View Revisions
2021-12-15 07:46 aiaustin Note Edited: 0038294 View Revisions
2021-12-15 07:46 aiaustin Note Edited: 0038294 View Revisions
2021-12-15 07:48 gimisa Note Edited: 0038294 View Revisions
2021-12-18 11:17 gimisa Note Edited: 0038294 View Revisions


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker