-
Notifications
You must be signed in to change notification settings - Fork 41
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
Number of subflows is equal to zero when expecting 1. #327
Comments
Hello, Good idea to work on a lib for MPTCP! Here, you are looking at A reliable way to get the number of subflows is to use
Out of curiosity, why do you do the PS: you should avoid doing if (getsockopt(...) < 0) {
/* log error */
return -1;
}
return inf.mptcpi_subflows; (Also, it is strange to return a If this replies to your questions, please close the ticket. |
Hello @matttbe Thank you very much for your quick reply. Indeed, you do answer my question. Out of curiosity, why do you do the getsockopt() calls in C and the rest in Python? Why not doing everything in Python (using struct I guess to parse the buffer written by getsockopt()'s syscall)? => The reason I do so it's because I thought it would be better to handle most of the calls at the C level since we have more freedom of operations on the socket. In addition, if I'm not mistaken the Linux upstream implementation is not the same on MacOs, so I thought it would be better to handle it at the C level. The goal of the lib is to even propose path management in future releases, and I think it would be harder (even impossible) to achieve only at the Python level. Please correct me if I'm wrong. Thank you for your P.S it was indeed a mistake from me the function had to return an error flag not null. |
Mmh, yes, it depends on the point of view. You can find many libs in Python where they proudly say it is a "pure" Python implementation: it is often easier to maintain (nothing to compile, no external dependences, etc.). I understand it is easier to do the I think it might be more interesting for a longer term to do all of that in Python directly. It will probably be a bit painful to define the
Yes, the API is different. I don't know a lot about the implementation on MacOSx, I don't even know if you can use their API with C (
It would not be difficult, you need to talk to the kernel using Netlink and some specific structure. If you want to manage the "in-kernel" path-manager, doing that in Python is perfectly fine to me (I guess there are Netlink libs in Python to ease that part) and there is not a lot to discuss with the kernel, just the configuration bit you can already do with If you want to manage the "userspace" path-manager with hundreds/thousands of connections, it might not be a good idea to do that in Python. (mptcpd might be better for that ; also you need extra permissions to do that ; mptcpd can also be extended to be use as a lib for C programs → and why not using this extension with your lib :) ) But please note that managing the userspace PM is quite a different/bigger job than providing info to the application: the userspace PM is controlled with Netlink while what you are doing is around the socket API. I might prefer to say: if something is missing in mptcpd, first check if it would not be better to extend it than rewriting it :) |
Hello @matttbe, I can't thank you enough for your insight. Your feedback will be added to the lib, and it is indeed a better route to take. |
Hello,
I'm currently working a MPTCP C extension library for python for MPTCP, mptcplib. For this module, I'm trying to add a function to get the number of subflows used by a socket.
In the current version of the lib the user does do by doing :
[Client.py]
[Server.py]
However, when I run these two peers at the end of the execution I get that the number of subflows used is zero. The
ip mptcp monitor
shows the following logs :The host,
hostnamectl
:The C code that checks the number of subflows is :
Thank you all for your time. I'd love to give more information if what I gave above is not enough.
The text was updated successfully, but these errors were encountered: