[Enhancement] CPU load optimization #190

New Issue

2013-06-04T13:39:38+02:00

AyrA commented

2013-06-04 13:39:38 +02:00

(Migrated from github.com)

Issue

Currently a message is tried to be decrypted by the client, causing it to create high CPU load for long messages, even if they are undecryptable.

Expected Behavior

Only decrypt a message completely when required.

Implementation

To accomplish this, include a checksum of the first 16 encrypted bytes (or whatever the block size is) at the beginning of the encrypted Message. The checksum itself must be in the encrypted message to prevent it from being modified.

Result

The client will only decrypt big messages if the initial chunk was decrypted successfully, preventing high CPU load with increasing number of messages or large Messages in the network.

## Issue Currently a message is tried to be decrypted by the client, causing it to create high CPU load for long messages, even if they are undecryptable. ## Expected Behavior Only decrypt a message completely when required. ## Implementation To accomplish this, include a checksum of the first 16 encrypted bytes (or whatever the block size is) at the beginning of the encrypted Message. The checksum itself must be in the encrypted message to prevent it from being modified. ## Result The client will only decrypt big messages if the initial chunk was decrypted successfully, preventing high CPU load with increasing number of messages or large Messages in the network.

Atheros1 commented

2013-06-04 20:02:27 +02:00

(Migrated from github.com)

This would be easy to transition to the next time we use a new address version number. If we try to transition to it without a new address version number, it would obsolete old clients in a silent way on the switchover date. Shall we wait until that point?

AyrA commented

2013-06-04 21:41:00 +02:00

(Migrated from github.com)

Depends on how you feel about it. There even still are unencrypted broadcasts out there so some people will not update at all.
if you want to wait very long for a new address version I would use the same mechanism as with the broadcasts.
You should probably add a "compatibility list" to the wiki to show, which version is the minimum required to successfully communicate with the current protocol version.

Depends on how you feel about it. There even still are unencrypted broadcasts out there so some people will not update at all. if you want to wait very long for a new address version I would use the same mechanism as with the broadcasts. You should probably add a "compatibility list" to the wiki to show, which version is the minimum required to successfully communicate with the current protocol version.

Atheros1 commented

2013-06-04 22:50:50 +02:00

(Migrated from github.com)

Yeah, the people who don't upgrade is what I'm worried about. At least with the address version number change they'll be shown a message saying that they should upgrade their client in order to communicate with that person.

AyrA commented

2013-06-06 09:04:31 +02:00

(Migrated from github.com)

I would force clients to update (use new address version), non-updated old software is always an issue for the network and we can cause troubles.

Atheros1 commented

2013-06-06 22:51:24 +02:00

(Migrated from github.com)

I think that we are in agreement there; it is only a question of when to change: now or later. I'm currently leaning towards later because in all likelihood there will be other changes we'll want to make that will require a new address version number in the next few months.

AyrA commented

2013-06-06 22:57:34 +02:00

(Migrated from github.com)

In this case I would combine this change with your modifications.

AyrA commented

2013-06-14 01:02:45 +02:00

(Migrated from github.com)

There is a detailed discussion about this now: https://bitmessage.org/forum/index.php/topic,1731.0.html

This repo is archived. You cannot comment on issues.