[bisq-network/projects] Refactor send-message business logic in Connections (#28)

Florian Reimair notifications at github.com
Mon Apr 6 10:54:06 UTC 2020


> _This is a Bisq Network project. Please familiarize yourself with the [project management process](https://bisq.wiki/Project_management)._

## Description
<!-- Briefly summarize the proposed project. Strive for one or two sentences of plain language that any user, contributor or stakeholder will understand. -->

The business logic of sending messages needs some love. During https://github.com/bisq-network/bisq/pull/4047, it became apparent, that the logic might miss sending messages entirely. Main takeaways from the project:
- long term: ground work that improves reliability.
- short term: maybe get rid of spurious message loss

## Rationale
<!-- Make the case for the the project. Why is it important? Why should it be done now? What will happen if we don't do it or delay doing it? -->

### Why is it important?
- Messages are submitted to the connection asynchronously, thus, chances are that messages do not get sent because threads are abandoned, killed, time out, or a connection is closed before all message in queue are sent
- definitely explains why we see nasty walls of exceptions on app shutdown quite frequently
- concrete example: removeOfferMessages on shutdown may or may not be sent, depending on the timeouts and therefore on the performance of the host, network load, message load of the bisq app, seed node load, ...
- it can happen for more crucial messages (messages are messages are messages, there are no priorities built into them)
- might explain why we see messages getting lost

IMO:
- I consider this a high priority task
- given my >1,5 years experience with the p2p part of Bisq
- the p2p message handling needs cleanup and refactoring, technology is outdated, changing stuff is a minefield, there is synchronization everywhere which immediately causes deadlocks on the slightest change, attack counter measures are scattered throughout the code to make it almost impossible to understand how/if they work, yet alone understand, control and tweak them, copy-and-pasted spagetti code provides plenty of places for bugs to hide in
- however, I cannot provide a concrete issue # that will be fixed by working on this

### Why should it be done now? What will happen if we don't do it or delay doing it?

- consider it as basic maintenance
- thus, no, it does not have to be done now
- delaying it will work as well

however,
- we might just see a more robust network
- less lost messages
- eliminate unforeseen deadlock situations
- confine timing issues to the Connection, where they can be (at least) handled somehow
- track messages and see if they are actually sent

## Criteria for delivery
<!-- Make a checklist defining the end state of the project. How will we know that the project is complete, i.e. delivered? What will exist at the completion of this project that does not exist now? What will have changed? What communications, promotions and/or documentation will exist to ensure people know about these changes? -->

- [ ] have a test suit for message sending BL
- [ ] more robust code

## Measures of success
<!-- After this project has been delivered, how will we know whether it was a success? What can be measured to indicate that this project was worth the time, effort and compensation it cost? -->

- cleaner code
- maybe catch a few bugs we are not aware of yet

## Risks
<!-- What risks do we run by undertaking the project? What sensitive areas of code are to be modified? What negative implications might this project have on privacy, security, performance, compatibility, maintainability, user experience, etc? -->

- as always, changing the P2P part of Bisq is highestest risk
- this one only touches the message sending business logic, so the risk is somewhat confined. Yet, if nobody can send messages, the network is going to die as well.

## Tasks
<!-- Make a checklist defining in as much detail as is foreseeable who will need to do what in order to deliver the project. The checklist may be modified throughout the course of the project as new tasks emerge. Alternatively, once the project proposal is approved, you may choose to migrate the task checklist to a dedicated GitHub project board. -->

- [ ] create test suit for message sending business logic (ie. on Connection level)
- [ ] implement a proper message queue for messages to be sent
- [ ] implement a proper connection shutdown process, move away from dropping anything instantly
- [ ] gradually remove "external" message scheduling mechanics

## Estimates
<!-- Estimate the cost in USD of delivering this project. Indicate which teams are involved and provide subtotal estimates per team. This section need not be complete for the project proposal to be approved but must be complete for budget to be allocated. -->

hard to say, as the project will only show its true face once we are knee-deep into it. 

| Task | Amount [USD] |
| --- | ---:|
| create test suit | 1800,00 |
| message queue | 900,00 |
| remove "external" scheduling | 1200,00 |
| testing | 700,00 |
| other | 500,00 |
| **total** | **5100,00** |

## Notes
<!-- Include anything else worth mentioning about this project. This section is optional and should be omitted if empty. -->
- supersedes https://github.com/bisq-network/bisq/issues/4105
- followup to https://github.com/bisq-network/bisq/pull/4047


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/projects/issues/28
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200406/e47bbb3c/attachment.html>


More information about the bisq-github mailing list