GNUnet Messenger API: December 2023

Hey again,

I’ve completed the necessary steps to solve the issue I talked last time. There are now three options for service configuration on each peer to specify how many peers need to manage message exchange actively at minimum ( MESSENGER_MIN_ROUTERS ), whether the own peer takes part in this functionality temporarily when required to achieve this minimum ( MESSENGER_AUTO_ROUTING ) and whether the own peer automatically reconnects to other peers keeping at least one external connection ( MESSENGER_AUTO_CONNECTING ). More details can be read in the bugtracker.

This should improve the reliability of connections for applications quite a bit. Because those changes adjust defaults to always have at least three peers managing message exchange in a chat room. The exception is when less peers are connected to a chat room at all which should only be valid for private or direct chats with only one other person.

One remaining aspect of this issue is that I still need proper testing whether all these changes work as intended. Since I’ve started working on the messenger service in GNUnet, there have been changes regarding the testing environment. The new testing environment utilizes Linux’s network namespaces to run multiple peers inside virtual networks, potentially connected through virtual switches with firewalls and NATs. I’ve started to implement a test case using this new enviroment but there are still issues which needs to be solved in its API.

Hopefully this can be sorted out soon. Otherwise I have to rely on practical testing on application level for now. So this might delay changes on the service level quite a bit. Theoretically the new testing environment will provide much more control and reproducibility of results than the previous testbed API.

Kind regards,
Jacki

Read original article

Popular posts from this blog

GNUnet Messenger API: March

GNUnet Messenger API: September

GNUnet Messenger API: December