Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Implement Tox network profiler #1885

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

JFreegman
Copy link
Member

@JFreegman JFreegman commented Jan 14, 2022

This change is Reviewable

@JFreegman JFreegman added the enhancement New feature for the user, not a new feature for build script label Jan 14, 2022
@JFreegman JFreegman added this to the v0.2.x milestone Jan 14, 2022
@JFreegman JFreegman force-pushed the netprof branch 11 times, most recently from b93009f to 75fd324 Compare January 14, 2022 20:13
toxcore/net_profile.c Outdated Show resolved Hide resolved
toxcore/net_profile.c Outdated Show resolved Hide resolved
toxcore/net_profile.h Outdated Show resolved Hide resolved
toxcore/net_profile.h Outdated Show resolved Hide resolved
toxcore/TCP_client.h Outdated Show resolved Hide resolved
toxcore/tox_private.h Show resolved Hide resolved
toxcore/tox_private.h Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented Jan 15, 2022

Codecov Report

Attention: Patch coverage is 70.05348% with 56 lines in your changes missing coverage. Please review.

Project coverage is 72.99%. Comparing base (102a1fa) to head (e740b4e).
Report is 6 commits behind head on master.

Files with missing lines Patch % Lines
toxcore/tox_private.c 57.40% 46 Missing ⚠️
toxcore/net_profile.c 90.69% 4 Missing ⚠️
toxcore/TCP_connection.c 71.42% 2 Missing ⚠️
toxcore/net_crypto.c 66.66% 2 Missing ⚠️
toxcore/TCP_server.c 83.33% 1 Missing ⚠️
toxcore/network.c 88.88% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1885      +/-   ##
==========================================
- Coverage   73.08%   72.99%   -0.09%     
==========================================
  Files         149      150       +1     
  Lines       30531    30714     +183     
==========================================
+ Hits        22313    22420     +107     
- Misses       8218     8294      +76     
Flag Coverage Δ
72.99% <70.05%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@iphydf iphydf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 10 of 19 files at r1, 8 of 9 files at r2, all commit messages.
Reviewable status: :shipit: complete! 1 of 1 approvals obtained (waiting on @JFreegman)


toxcore/tox_private.h, line 60 at r1 (raw file):

Previously, JFreegman wrote…

The reason I named it ZERO is because it has a different purpose depending on the packet type (see the above comment). Any suggestions?

Ok, that's fine then.

@pull-request-attention pull-request-attention bot assigned JFreegman and unassigned iphydf Jan 15, 2022
Copy link
Member

@iphydf iphydf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 1 of 19 files at r1.
Reviewable status: :shipit: complete! 1 of 1 approvals obtained (waiting on @JFreegman)

Copy link
Member

@Green-Sky Green-Sky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For testing, we should be able to inject a custom struct Network and compare total packet numbers there.

TOX_NETPROF_DIRECTION_RECV);
}

const unsigned long long total_packets = total_sent_count + total_recv_count;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally prefer size named types like uint64_t over unsigned long long.

@@ -18,6 +18,7 @@
#include "DHT.h"
#include "Messenger.h"
#include "TCP_client.h"
#include "TCP_server.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this right?

@@ -20,6 +20,7 @@
#include "logger.h"
#include "mem.h"
#include "mono_time.h"
#include "net_profile.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some places, like here, don't need to know the full type and a forward declaration instead would suffice.

@@ -15,6 +15,7 @@
#include "logger.h"
#include "mem.h"
#include "mono_time.h"
#include "net_profile.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here too.

@@ -10,6 +10,7 @@
#include "crypto_core.h"
#include "logger.h"
#include "mem.h"
#include "net_profile.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here. (we only store a pointer)

@@ -15,6 +15,7 @@
#include "logger.h"
#include "mem.h"
#include "mono_time.h"
#include "net_profile.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or here.

@@ -20,6 +20,7 @@
#include "logger.h"
#include "mem.h"
#include "mono_time.h"
#include "net_profile.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here too ... i feel like we should forward declare it in some public places.

@@ -999,6 +1008,11 @@ int send_packet(const Networking_Core *net, const IP_Port *ip_port, Packet packe
loglogdata(net->log, "O=>", packet.data, packet.length, ip_port, res);

assert(res <= INT_MAX);

if (res == packet.length) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i saw a data != nullptr earlier, should it be put everywhere, like here too?

* Bootstrap info packet.
*/
TOX_NETPROF_PACKET_ID_BOOTSTRAP_INFO = 0xf0,
} Tox_Netprof_Packet_Id;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all public facing enums in toxcore now have a *_to_string() function. Since there are alot of values here, it would be very valuable.
Maybe it can also take in the type (tcp/udp), to print a sensible string? or maybe I am just dreaming here...

@Green-Sky
Copy link
Member

I get a lot of 0x10 udp packets, which are

    /**
     * TCP data packet.
     */
    TOX_NETPROF_PACKET_ID_TCP_DATA             = 0x10,

supposed to be tcp according to your code.

@Green-Sky
Copy link
Member

example table

tomato_Image_2024-09-22_14-29-49 922

@Green-Sky
Copy link
Member

The beating heath of a toxcore:

tomato_netprof_tableheat2.mp4

@JFreegman
Copy link
Member Author

JFreegman commented Sep 24, 2024

I get a lot of 0x10 udp packets, which are

    /**
     * TCP data packet.
     */
    TOX_NETPROF_PACKET_ID_TCP_DATA             = 0x10,

supposed to be tcp according to your code.

Are you sure that's not a custom packet ID in your client/modified toxcore? I'm not seeing the same thing with Toxic. If you disable UDP you should see that it doesn't record any UDP packets at all, so if that's the case it definitely has to be a UDP packet with an invalid ID, in which case toxcore should be logging it.

Edit: It appears that you're recording 0x10 as a TCP ID as well in that bottom video.

@Green-Sky
Copy link
Member

Are you sure that's not a custom packet ID in your client/modified toxcore? I'm not seeing the same thing with Toxic.

Yep, I am running master with netprof, no "modified" toxcore in that sense.

If you disable UDP you should see that it doesn't record any UDP packets at all, so if that's the case it definitely has to be a UDP packet with an invalid ID, in which case toxcore should be logging it.

Disabling UDP looks normal.
image

Edit: It appears that you're recording 0x10 as a TCP ID as well in that bottom video.

Well yes. BTW, I copied the names/descriptions from the enum and there are some inconsistencies.

@Green-Sky
Copy link
Member

Ok, after setting a conditional breakpoint and not hitting any UDP, I checked your code and found this.

// Special case - TCP data packets can have any ID between 0x10 and 0xff
if (id == NETPROF_TCP_DATA_PACKET_ID) {
return netprof_get_packet_count_id_range(profile, id, UINT8_MAX, dir);
}

I think the way this is done leads to confusion. It should not be done at the lower level, since profile does not know whether it is UDP or TCP...

@JFreegman
Copy link
Member Author

JFreegman commented Sep 24, 2024

Ok, after setting a conditional breakpoint and not hitting any UDP, I checked your code and found this.

// Special case - TCP data packets can have any ID between 0x10 and 0xff
if (id == NETPROF_TCP_DATA_PACKET_ID) {
return netprof_get_packet_count_id_range(profile, id, UINT8_MAX, dir);
}

I think the way this is done leads to confusion. It should not be done at the lower level, since profile does not know whether it is UDP or TCP...

I'm not sure what you mean. I'm not sure how your client ended up thinking those were UDP packets. It knows they're TCP packets because you passed a TCP packet ID and TCP profile to the function (netprof_get_packet_count_id()). If you had passed the UDP profile to that function with that same packet ID it would return 0.

@Green-Sky
Copy link
Member

I'm not sure what you mean. I'm not sure how your client ended up thinking those were UDP packets. It knows they're TCP packets because you passed a TCP packet ID and TCP profile to the function (netprof_get_packet_count_id()). If you had passed the UDP profile to that function with that same packet ID it would return 0.

I prefer to use a simple for loop for 0-255, since it is forward compatible and covers custom packet ranges. Also your current solution would not allow us to use 0x10 for UDP packets in the future, since its just magic behavior, independent of whether it is UDP or TCP.
It should also be a simple code removal, so less code ...
I am also not a fan on how UDP and TCP share the same ID enum, it makes it less ergonomic to use imho.
I would however like to see the *_range() variants elevated to the "public" private api.

@JFreegman
Copy link
Member Author

JFreegman commented Sep 25, 2024

@Green-Sky

I prefer to use a simple for loop for 0-255, since it is forward compatible and covers custom packet ranges

0x00 through 0x09 are already in use. 0x10 through 0x255 are all data packet ID's, which includes custom packets. As far as forward compatibility goes, if we were to change TCP data packet ID's, we would completely break the TCP implementation regardless.

Also your current solution would not allow us to use 0x10 for UDP packets in the future, since its just magic behavior, independent of whether it is UDP or TCP.

I don't think you understand how recording/querying works. There are already numerous packet ID's that are used for UDP and TCP (which is why the API enums have shared ID's). There are three distinct profiles - TCP server, TCP client, and UDP, which are queried using the Tox_Netprof_Packet_Type enum. If you query packet ID 0x10 for UDP, then it will only give you information for UDP packets with the ID 0x10, while ignoring those ID's for the TCP profiles. A TCP packet with the ID 0x10 will not affect the UDP profile, regardless of whether or not there exists a UDP packet with the ID 0x10. That's why I'm not understanding how you ended up with your client thinking that 0x10 is a UDP packet ID.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature for the user, not a new feature for build script
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants