p2p-today / p2p-project Goto Github PK

Things should not be used before they are defined

Currently if you connect to someone with a different protocol it will silently fail. This is a rather large flaw.

• connection method
• join method
• handshakes
• correct routing tables
• periodic network updates
• storage
• retreival
• unit tests

Currently it's sending things like ["localhost", 44444] or ["0.0.0.0", 44444].

Neither of these are valid outward facing addresses.

• Make more variables private
• Centralize imports
• Reorder functions in "who's called first" order
• Clear up if statements in recv()
• Add comment documentation
• Try to shorten code

@ajacques

Question is, why is it so inconsistent?

Issue started as of 01dd164

Currently I'm leaning towards AppVeyor, as it allows me to reset the count on each version change.

That might be a bad thing, though, as it means the build number will not be unique. It may be better to go for a unique, constantly increasing build number, so that people can more easily track API changes.

Of the two remaining, Shippable will be the best at keeping build numbers unique, as it will always be higher than Travis. This breaks if you pull from an active branch, but does not if releases are done properly.

https://codeclimate.com/github/gappleto97/p2p-project/py_src/mesh.py

Warnings already added to develop branch. Deprecation scheduled for two releases from now.

As in, the next release will contain warnings, the release after will remove.

Looks like I left the doc string from an old version

One thing to make sure of would be that a copy is kept on my account in case base58 disappears from pypi. It would be good to see if conditional installations can work with setup.py before proceeding.

The following code should help out:

import struct

def key_to_bin(key):
    arr = []
    while key:
        arr = [key % 256] + arr
        key //= 256
    return struct.pack("!" + "B" * len(arr), *arr)

def key_from_bin(key):
    arr = struct.unpack("!" + "B" * len(key), key)
    i = 0
    for n in arr:
        i *= 256
        i += n
    return i

def predict_len(keysize):
    length = (keysize + 7) // 8
    return length

def test(iters):
    for i in range(1, iters + 1):
        test = 2**i - 1
        assert test == key_from_bin(key_to_bin(test))
        assert len(key_to_bin(test)) == predict_len(i)

Using Q instead of B may improve CPU time, at the cost of ~8 bytes average. This effect should be minimal, however, depending on how struct works internally. If it works in the naive way I think it does, then this just reduces its workload proportional to this method's increased workload.

This will allow arbitrary complication without forcing net.py to get longer

Is this possible to fix?

This is probably not feasible to fix, but a perfect example of this race condition can be found in the test_conn_error_recovery_SSL() method, on develop branch

Build:

• OSX
• Linux
• Windows

As of this issue's creation, Windows has not yet completed its run. If it also fails, this issue will receive an additional label.

This error appears to not be the key-storage bug that was affecting python 3.3+, so this will need to be debugged on a local system. My best guess is that it's a timing issue, since there will almost certainly be thread clutter. Figuring out how to clean these up better will help, though it may not solve the problem.

In reference to #52

This will allow the network to repair itself over time

Drawback: it means testing poorly connected scenarios becomes harder

https://ci.appveyor.com/project/gappleto97/p2p-project/build/job/9qb5dkpvvitj73rp

Step 1: figure out how to generate a self signed certificate with the fewest dependencies possible (and a range of them, where any are needed)

Current candidates: PyOpenSSL, cryptography, PyCrypto?

Step 2: figure out a way to guarantee the removal of certificate files after exit, or find a way to feed it as an object instead

This will help segregate deconstructor features

Pursuant to the completion of #38

Note that this is likely not a concurrency limitation, as the bug also occurs when testing via multiprocessing.

Steps to reproduce:

1. Start three instances of python, two python2, one python3
2. Connect python3 to python2a
3. Connect python2b to python2a
4. Watch python2b connect to, then disconnect from python3

What's going on here? It looks as if python2b is closing the socket first, but I can't see an explanation why. Furthermore, if you reverse the order of connection, the bug doesn't seem to occur. When it does occur, no exceptions are added to the queue.

There needs to be testing for the various network functions. Unfortunately, the CIs don't seem to like this very much.

Bonus goal: Figure out how to do this while maintaining a private API

Keeps throwing attribute errors for seemingly no reason. Explanations are in order.

Looks like they just don't have bz2. If that's all it is, I'm happy to add a try-catch to fix that.

Proposal: add 1 byte to size header which describes the length of the size header and packet header. New structure would be roughly:

1. 1 byte describing header length
2. X bytes describing message length
3. Xn bytes describing packet layout
4. Packets

For automated messages this saves ~11 bytes each. It also expands the possible message size/packet length from 256⁴-1 to 256²⁵⁵-1.

The question is, does this render a sufficiently large increase in complexity that it's not worth it? For instance, this means that struct will no longer work for the purpose. This will have lots of effects on how fast/slow the program becomes, and it may not be worth it.

Strangely, this may make the Javascript side easier, as it forces me to remove a dependency.

Plaintext:

• Propagation
• Protocol Rejection
• Response
• Socket disconnect recovery
• Socket shutdown recovery
• Message reply
• Custom handler registry
• Inactive socket test
• Compression renegotiation

SSL

• Propagation
• Protocol Rejection
• Response
• Socket disconnect recovery
• Socket shutdown recovery
• Message reply
• Custom handler registry
• Inactive socket test
• Compression renegotiation

Write from the perspective of constructing a node. This will help ensure the best comprehension.