Unused code in shared and protocol modules #1374
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-21#1374
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello.
The functions
checkAndShareObjectWithPeers
,_checkAndShareUndefinedObjectWithPeers
,_checkAndShareMsgWithPeers
,_checkAndShareGetpubkeyWithPeers
,_checkAndSharePubkeyWithPeers
,_checkAndShareBroadcastWithPeers
are same inprotocol
andshared
modules and used from latter as I can see.Remove it from
protocol
?The only place where
checkAndShareObjectWithPeers()
appears is class_objectProcessor.py#L751 butbroadcastToSendDataQueues
seems to be useless, because I cannot find wheresendDataQueues
are handled.In general
shared
should be reduced as much as possible. Just check that the code inprotocol
is working correctly and nothing references the removed functions from shared.Regarding
check*
, this is supposed to be obsoleted because there are new check implementations inBMObject
. As far as I can see, there is only one reference to them, fromclass_objectProcesor
when you extract an ACK from a message, you call these checks before putting the ACK into the inventory. This should be refactored to useBMObject
(maybe some extra coding is necessary, I'm not sure if they are compatible, I think I didn't pay enough attention during moving to asyncore), and the checks from bothprotocol
andshared
should be removed.Regarding
broadcastToSendDataQueues
andsendDataQueues
, I'm pretty sure they are obsolete as asyncore doesn't use them anymore. Maybe they are even creating a memory leak.I looked at it and it definitely does need extra work as the
BMObject
constructor requires decoded arguments, and the decoder only works on buffers. So some redesign is necessary if we're to avoid duplication of code.Maybe create a fake
BMProto
objecto
, copy the buffer from the ACK buffer (or just reference it), and callo.bm_command_object()
to process it. Probably some additional tests are necessary.I found that I do not understand where objects are broadcasted to the network ):
I have a rather controversial solution: 03ee14e9.