Need a tool that can simply test BDT protocol connectivity #141
Comments
|
Hi, the code for this feature has been submitted to the 853d4c8 of Git. Assuming that the remote host is u1 and the local host is u2, with the IP addresses of 192.168.10.100 and 192.168.20.100, respectively. On u2, with the certificate of u1 named u1.desc available, the following steps are taken to determine the BDT connectivity to u1: 1.Compile the debug program Copy bdt-debugger-daemon and bdt-debugger to u2, and put sn-miner.desc, sn-miner.sec, u1.desc, and u1.sec into the same directory. 2.Start the local debug program on u2 3.Perform ping debugging 4.The results Online, ping successfully: Offline, ping failed: |
|
Great Job! But why need 2 programs to test bdt prorocol stack? Is it possible use single program to test it? |
|
Hello. It is inconvenient to debug the BDT protocol stack using only one program. The bdt-debuger-deamon integrates all the functions of the BDT protocol stack and outputs logs during runtime. bdt-debuger serves as a bridge between bdt-debuger-deamon and the user, transmitting commands to bdt-debuger-deamon for execution and displaying the results. Currently, if there is only one program(bdt-debuger-deamon), the logs and inputs during runtime will be mixed together, which can affect the interaction. And the feature to load multiple SNs will be added later. |
|
Hi, you can initialize the local BDT stack with a SN list now. |
Is this tool available for use now? Are there any detailed usage processes and instructions? |
lurenpluto
added
the
Beginner-Friendly
Yes, both bdt-debuger-deamon and bdt-debuger are available. For specific usage, please refer to the document at https://github.com/buckyos/documents/blob/main/bdt/en/9.Debug.md. Additional features will be added in the future, and any changes in usage will be updated in this document. |
A nice tool, thank you for providing it! I will give it a try with my OOD. |
|
@jing-git I want to integrate this function into the cyfs-monitor program to detect whether a given OOD is connectable or not. What would be the best way for me to do this? |
|
There is a key question |
|
I think you can refer to the design of cyfs-meta-client and cyfs-meta-lib. cyfs-meta-lib is a rust lib, and this lib defines the MetaClient structure. By constructing the MetaClient example. Third-party programs can interact with the Meta chain through the interface of this instance Further, cyfs-meta-client is a command line tool through which it is possible to interact with the MetaChain in a shell. This tool has several functions, but the logic of implementing each function is similar: 1:
|
|
What is the purpose of this BDT tool? As a network protocol testing tool, if it is only used to diagnose the running status of the server, we can use simple bdt client tools like ping/nc to achieve it, in order to diagnose whether the server BDT protocol can be connected correctly. But if this tool is used to diagnose the connectivity and data transmission performance of BDT between two nodes, we need more professional testing tools, such as iperf, and specify whether to run as a client or server using -c and -s. It seems that the current implementation leans towards providing a server + client tool that is similar to iperf for professional users. However, the daemon and debug programs can be combined into one program. For example nc: root@filecoin2:/# nc -help
OpenBSD netcat (Debian patchlevel 1.218-4ubuntu1)
usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl]
[-m minttl] [-O length] [-P proxy_username] [-p source_port]
[-q seconds] [-s sourceaddr] [-T keyword] [-V rtable] [-W recvlimit]
[-w timeout] [-X proxy_protocol] [-x proxy_address[:port]]
[destination] [port]
Command Summary:
-4 Use IPv4
-6 Use IPv6
-b Allow broadcast
-C Send CRLF as line-ending
-D Enable the debug socket option
-d Detach from stdin
-F Pass socket fd
-h This help text
-I length TCP receive buffer length
-i interval Delay interval for lines sent, ports scanned
-k Keep inbound sockets open for multiple connects
-l Listen mode, for inbound connects
-M ttl Outgoing TTL / Hop Limit
-m minttl Minimum incoming TTL / Hop Limit
-N Shutdown the network socket after EOF on stdin
-n Suppress name/port resolutions
-O length TCP send buffer length
-P proxyuser Username for proxy authentication
-p port Specify local port for remote connects
-q secs quit after EOF on stdin and delay of secs
-r Randomize remote ports
-S Enable the TCP MD5 signature option
-s sourceaddr Local source address
-T keyword TOS value
-t Answer TELNET negotiation
-U Use UNIX domain socket
-u UDP mode
-V rtable Specify alternate routing table
-v Verbose
-W recvlimit Terminate after receiving a number of packets
-w timeout Timeout for connects and final net reads
-X proto Proxy protocol: "4", "5" (SOCKS) or "connect"
-x addr[:port] Specify proxy address and port
-Z DCCP mode
-z Zero-I/O mode [used for scanning]
Port numbers can be individual or ranges: lo-hi [inclusive]For example iperf: root@filecoin2:/# iperf --help
Usage: iperf [-s|-c host] [options]
iperf [-h|--help] [-v|--version]
Client/Server:
-b, --bandwidth #[kmgKMG | pps] bandwidth to read/send at in bits/sec or packets/sec
-e, --enhanced use enhanced reporting giving more tcp/udp and traffic information
-f, --format [kmgKMG] format to report: Kbits, Mbits, KBytes, MBytes
--hide-ips hide ip addresses and host names within outputs
-i, --interval # seconds between periodic bandwidth reports
-l, --len #[kmKM] length of buffer in bytes to read or write (Defaults: TCP=128K, v4 UDP=1470, v6 UDP=1450)
-m, --print_mss print TCP maximum segment size (MTU - TCP/IP header)
-o, --output <filename> output the report or error message to this specified file
-p, --port # client/server port to listen/send on and to connect
--permit-key permit key to be used to verify client and server (TCP only)
--sum-only output sum only reports
-u, --udp use UDP rather than TCP
-w, --window #[KM] TCP window size (socket buffer size)
-z, --realtime request realtime scheduler
-B, --bind <host>[:<port>][%<dev>] bind to <host>, ip addr (including multicast address) and optional port and device
-C, --compatibility for use with older versions does not sent extra msgs
-M, --mss # set TCP maximum segment size (MTU - 40 bytes)
-N, --nodelay set TCP no delay, disabling Nagle's Algorithm
-S, --tos # set the socket's IP_TOS (byte) field
-Z, --tcp-congestion <algo> set TCP congestion control algorithm (Linux only)
Server specific:
-p, --port #[-#] server port(s) to listen on/connect to
-s, --server run in server mode
-1, --singleclient run one server at a time
--histograms enable latency histograms
--permit-key-timeout set the timeout for a permit key in seconds
--tcp-rx-window-clamp set the TCP receive window clamp size in bytes
--tap-dev #[<dev>] use TAP device to receive at L2 layer
-t, --time # time in seconds to listen for new connections as well as to receive traffic (default not set)
--udp-histogram #,# enable UDP latency histogram(s) with bin width and count, e.g. 1,1000=1(ms),1000(bins)
-B, --bind <ip>[%<dev>] bind to multicast address and optional device
-U, --single_udp run in single threaded UDP mode
--sum-dstip sum traffic threads based upon destination ip address (default is src ip)
-D, --daemon run the server as a daemon
-V, --ipv6_domain Enable IPv6 reception by setting the domain and socket to AF_INET6 (Can receive on both IPv4 and IPv6)
Client specific:
-c, --client <host> run in client mode, connecting to <host>
--connect-only run a connect only test
--connect-retries # number of times to retry tcp connect
-d, --dualtest Do a bidirectional test simultaneously (multiple sockets)
--fq-rate #[kmgKMG] bandwidth to socket pacing
--full-duplex run full duplex test using same socket
--ipg set the the interpacket gap (milliseconds) for packets within an isochronous frame
--isochronous <frames-per-second>:<mean>,<stddev> send traffic in bursts (frames - emulate video traffic)
--incr-dstip Increment the destination ip with parallel (-P) traffic threads
--incr-dstport Increment the destination port with parallel (-P) traffic threads
--incr-srcip Increment the source ip with parallel (-P) traffic threads
--incr-srcport Increment the source port with parallel (-P) traffic threads
--local-only Set don't route on socket
--near-congestion=[w] Use a weighted write delay per the sampled TCP RTT (experimental)
--no-connect-sync No sychronization after connect when -P or parallel traffic threads
--no-udp-fin No final server to client stats at end of UDP test
-n, --num #[kmgKMG] number of bytes to transmit (instead of -t)
-r, --tradeoff Do a fullduplexectional test individually
--tcp-write-prefetch set the socket's TCP_NOTSENT_LOWAT value in bytes and use event based writes
-t, --time # time in seconds to transmit for (default 10 secs)
--trip-times enable end to end measurements (requires client and server clock sync)
--txdelay-time time in seconds to hold back after connect and before first write
--txstart-time unix epoch time to schedule first write and start traffic
-B, --bind [<ip> | <ip:port>] bind ip (and optional port) from which to source traffic
-F, --fileinput <name> input the data to be transmitted from a file
-H, --ssm-host <ip> set the SSM source, use with -B for (S,G)
-I, --stdin input the data to be transmitted from stdin
-L, --listenport # port to receive fullduplexectional tests back on
-P, --parallel # number of parallel client threads to run
-R, --reverse reverse the test (client receives, server sends)
-S, --tos IP DSCP or tos settings
-T, --ttl # time-to-live, for multicast (default 1)
-V, --ipv6_domain Set the domain to IPv6 (send packets over IPv6)
-X, --peer-detect perform server version detection and version exchange
Miscellaneous:
-x, --reportexclude [CDMSV] exclude C(connection) D(data) M(multicast) S(settings) V(server) reports
-y, --reportstyle C report as a Comma-Separated Values
-h, --help print this message and quit
-v, --version print version information and quit
|
How do you test the connectivity between the local machine and an already started, BDT stack via nc? I think only BDT provides a specific tool to test |
It mainly depends on the different levels of requirements
|
hello, you can directly use the ping interface of Pinger.：https://github.com/buckyos/CYFS/blob/main/src/component/cyfs-bdt/src/debug/ping.rs /*
stack: WeakStack
remote: Device
timeout: Duration
*/
let pinger = Pinger::open(stack.clone()).unwrap();
match pinger.ping(remote.clone(), timeout, "debug".as_ref()).await {
Ok(rtt) => {
match rtt {
Some(rtt) => {
println!("ping success, rtt is {:.2} ms", rtt as f64 / 1000.0);
},
None => {
println!("connected, but ping's seq mismatch");
}
}
},
Err(e) => {
println!("ping err={}", e);
}
} |
The previous design was more focused on debugging and observing the running process. For ease of use, i will combine the daemon and debugger into one program later, which can directly receive commands, process them, and return results. |
|
Hello, you can use easier-to-use tool right now. It provides ping and nc functions to quickly check the connectivity of the peer device and has only one program. compile: Command line: Examples:
If you want to see more information about the running process, you can add the parameter log_level, like "--log_level info". |
jing-git
modified the milestones:
Performance Optimization and Bug Fix Release,
Restore Service and Dynamic permission Release
|
@jing-git I think you should put our beta and nighlty SN into the tool, other people may not know our complete SN List，You can set beta sn list default ,and use channel param to config it . |
|
So should we public the beta & nightly desc file
Of course they can be integrated into the tool. |
|
@jing-git @lurenpluto I don't think the current bdt-tool is friendly for novice users to diagnose the BDT network. Just like the traditional ping tool, there is no need for users to input their own IP and DNS host as this is handled internally by the tool, And similarly, endpoints and SN lists can be embedded in the BDT-tool , Needn`t input Ping
|
One of the key principles of our tool design is to put ourselves in the user's shoes, to make it simple enough to use, and not prone to ambiguity and confusion The command line of the tool should be improved from the following perspectives. 1. 1. the --ep parameter inside is too complexThe use of bdt internal endpoint coding format, of course, this user can provide is the most accurate, but the general user does not know what the meaning of this, for the need for 2. Need to support deviceOur bdt protocol connection is based on device.desc, the endpoint list is only a part of it, so the most intuitive way for bdt tool to test the connection is to specify device.desc or device_id directly, which is the most consistent with the bdt protocol command line. 3. sn_list selectionIf sn is not explicitly specified in the parameters, then use the sn list on the corresponding meta chain, which we also have a fixed logic to pull the corresponding sn list |
lurenpluto
modified the milestones:
Restore Service and Dynamic permission Release,
GC-supported Release,
Group-supported Release
|
New features have been updated for bdt-tool, you can update the code and use it after compiling. Usage example:
Try to ping device_id 5aSixgLro2HUD6djQRT82dLdXNBjF7trBUczRu7piH9A 3 times, timeout is 5 sec.
Try to connect device_id 5aSixgLro2HUD6djQRT82dLdXNBjF7trBUczRu7piH9A vport 2021. |
We need a tool to enter a DeviceId that can test the connectivity between the local machine and this DeviceId. In this way:
In addition, a simple Ping/Pong protocol can be used to test whether data can be transferred between BDT protocol stacks, and by extending the contents of the Pong return packet, it is also possible to
The text was updated successfully, but these errors were encountered: