mtcp | Highly Scalable User-level TCP Stack | Continuous Deployment library

by mtcp-stack C Version: v2.1 License: Non-SPDX

X-Ray Key Features Code Snippets Community Discussions(4)Vulnerabilities Install Support

kandi X-RAY | mtcp Summary

mtcp is a C library typically used in Devops, Continuous Deployment, Docker applications. mtcp has no bugs, it has no vulnerabilities and it has medium support. However mtcp has a Non-SPDX License. You can download it from GitHub.

mTCP: A Highly Scalable User-level TCP Stack for Multicore Systems

Support

Quality

Security

License

Reuse

Support

mtcp has a medium active ecosystem.

It has 1838 star(s) with 425 fork(s). There are 152 watchers for this library.

It had no major release in the last 12 months.

There are 78 open issues and 192 have been closed. On average issues are closed in 165 days. There are 13 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of mtcp is v2.1

Quality

mtcp has no bugs reported.

Security

mtcp has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

License

mtcp has a Non-SPDX License.

Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

Reuse

mtcp releases are available to install and integrate.

Installation instructions, examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of mtcp

Get all kandi verified functions for this library.

mtcp Key Features

No Key Features are available at this moment for mtcp.

mtcp Examples and Code Snippets

No Code Snippets are available at this moment for mtcp.

Community Discussions

Trending Discussions on mtcp

Does DPDK provide a native TCP/IP network stack implemetation?

container is not able to access other container port

Exception, but only on 3rd time - The IAsyncResult object was not returned from the corresponding asynchronous method on this class

Read TCP Options Fields

QUESTION

Does DPDK provide a native TCP/IP network stack implemetation?

Asked 2021-Jan-24 at 04:17

I'm trying to find out if there is any native TCP/IP stack implemetation provided in DPDK or any popular open-source project to achieve it. Any help will be grateful.

Update: My platform is Ubuntu 16.04 x64, Intel 82599es NIC with DPDK 20.08. What I'm trying to accomplish is to rebuild TCP connections out of the packets I receive on the NIC port for later use. I thought tools like ANS, mTCP and fstack may do the track but they are third party and some of them are not fully open-sourced, so I'm looking for a native one or one that is popular for developers. I don't know what should I call this kind of requirement, sorry for troubles causing because of the question, I'll change it after I know the related concept better.

...

ANSWER

Answered 2021-Jan-24 at 04:17

There are no native TCP-IP stack implementation in DPDK version till date DPDK version 20.11 LTS. Going further in my humble opinion DPDK would not be implementing native TCP-IP stack. Hence current options are

Since the requirement is to rebuild TCP connection state information, my recommendation is to

create RTE_FLOW_ACTION_MIRROR to create the packet copy at HW NIC level for all interested TCP connection using a combination of IP-TCP address-ports.
If there is no HW option, either using ref_cnt_update or copying the user packet payload create a copy of the packet.
With help RTE_RINGS or RTE_FB_ARRAY organize the packets from client and server based on symmetric RSS (if available) or based on custom HASH to appropriate containers.
For you packet processing recommendation is either use FSTACK or mTCP or BSD TCP-ip from scratch

there are multiple references on the Internet which gives hints to get started too. Please refer

mTCP slide 14
fstack slide deck

Source https://stackoverflow.com/questions/65841190

QUESTION

container is not able to access other container port

Asked 2020-Feb-05 at 09:12

I have a container that runs jupyter-hub on 443 and mapped to 1443 on the host. I'm trying to run this server behind the apache in another container. But, the two containers are not able to talk to each other.

I have tried setting the iptables for each container, but no use.

...

ANSWER

Answered 2020-Feb-05 at 09:12

The problem when the 2 containers not able to talk to each other is due to the fact that they are not in the same docker network. Here are what you have to do:

List all the available networks: docker network ls
Find out which network the apache container is running in

Source https://stackoverflow.com/questions/60071510

QUESTION

Exception, but only on 3rd time - The IAsyncResult object was not returned from the corresponding asynchronous method on this class

Asked 2019-Aug-17 at 14:13

I have a legacy (2008) Windows service application (using System.ServiceProcess.ServiceBase) that I need to utilize in a slightly different way to how it's working now. At the moment it starts up and creates a TCPLISTENER on a specific port, for a client app to connect to (which it does once) in order to send/receive requests to the listening port. This all works fine. However, the adaptation requires use of a web app to connect to the listener port, then send/rcv as normal but after the receive it must DISCONNECT(*)

(* - if the web app didn't have to disconnect from the listening socket after each test that'd be better, but how I might achieve this is beyond me. Can I keep a TCP connection in session state for re-use?)

Anyway, the adaptation all works fine for the first TWO connect/send/rcv/disconnect tests but on the THIRD the service throws an ArgumentException in the EndAccept of the Socket class.

I don't understand why it is failing on the 3rd test.

Here is the simple test client.

...

ANSWER

Answered 2018-Mar-27 at 09:18

There is a similar issue raised and answered here

... you are holding the socket object in a class-scoped variable. So, if somehow the socket gets disconnected while the ReadCallback is executing and you reconnect it (thereby changing the socket object) - now they don't match, you are trying to complete the Async request using the new object when the old one is the one actually completing.

In your case it is the variable cState. On Connect method, if you just declare a new instance of cState locally which holds the socket then the error may stops occuring.

Source https://stackoverflow.com/questions/49427831

QUESTION

Read TCP Options Fields

Asked 2017-Mar-14 at 07:01

I'm linking linux/tcp.h and I'm trying to read the TCP options, I can't seem to find how to do so. I've read a bit online and according to some online sources I have to iterate all of the "remaining packet" until I hit the option(s) I want? (Right now I'm going to try and focus on the "MSS" option). Can anyone provide me with a code example of it?

...

ANSWER

Answered 2017-Mar-12 at 20:22

There are two possible answers: how to get the MSS (maximum segment size) of a TCP connection and how to parse the TCP header.

If all you want to know is what the MSS of the connection is, then you can use the getsockopt function on an open socket. Pass it the file descriptor, IPPROTO_TCP as the level, TCP_INFO as the option, the address of a struct tcp_info (from tcp.h) that will hold the output, and sizeof (struct tcp_info). The kernel will fill in the fields of struct tcp_info and you can get the MSS from tcpi_snd_mss or tcpi_rcv_mss.

If you actually want to parse the TCP header itself, then you have to understand the layout of the header. The struct tcphdr you're using doesn't include the options, which come after the fields in struct tcphdr. Each option field is a single byte identifying the option kind, optionally followed by a second byte specifying the size of the option (including the kind and size bytes), followed by additional data.

There may not be any options at all. You have to start by looking at the data offset field of the TCP header (doff). It's in 32-bit words. The size of the standard header, defined by struct tcphdr, is 20 bytes, so options can only be present if doff is greater than 5 (times 4 bytes = 20 bytes).

Assuming there are options, you can read them like this. Note that option kind for MSS is 2 and that option kind 0 signifies the end of the options list, but only if the end of the options list doesn't already coincide with the start of the data as per doff. Option kinds 0 and 1 (no-op) are a single byte. The other option kinds have a size byte that follows the kind and specifies the size of the options field (including the kind and size fields).

Source https://stackoverflow.com/questions/42750552

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install mtcp

mTCP can be prepared in four ways. Bring the dpdk compatible interfaces up, and then set RTE_SDK and RTE_TARGET environment variables. If you are using Intel NICs, the interfaces will have dpdk prefix. Please note that your NIC should support RSS queues equal to the MAX_CPUS value (since mTCP expects a one-to-one RSS queue to CPU binding). Check the configurations in apps/example. You can revert back all your changes by running the following script. Please note that your NIC should support RSS queues equal to the MAX_CPUS value (since mTCP expects a one-to-one RSS queue to CPU binding). Check the configurations in apps/example. NEW: Now you can run mTCP applications (server + client) locally. A local setup is useful when only 1 machine is available for the experiment. ONVM configurations are placed as .conf files in apps/example directory. ONVM basics are explained in https://github.com/sdnfv/openNetVM.
Download DPDK submodule. git submodule init git submodule update
Setup DPDK. ./setup_mtcp_dpdk_env.sh [<path to $RTE_SDK>] Press [15] to compile x86_64-native-linuxapp-gcc version Press [18] to install igb_uio driver for Intel NICs Press [22] to setup 2048 2MB hugepages Press [24] to register the Ethernet ports Press [35] to quit the tool Only those devices will work with DPDK drivers that are listed on this page: http://dpdk.org/doc/nics. Please make sure that your NIC is compatible before moving on to the next step. We use dpdk/ submodule as our DPDK driver. FYI, you can pass a different dpdk source directory as command line argument.
Bring the dpdk compatible interfaces up, and then set RTE_SDK and RTE_TARGET environment variables. If you are using Intel NICs, the interfaces will have dpdk prefix. sudo ifconfig dpdk0 x.x.x.x netmask 255.255.255.0 up export RTE_SDK=`echo $PWD`/dpdk export RTE_TARGET=x86_64-native-linuxapp-gcc
Setup mtcp library: ./configure --with-dpdk-lib=$RTE_SDK/$RTE_TARGET make By default, mTCP assumes that there are 16 CPUs in your system. You can set the CPU limit, e.g. on a 32-core system, by using the following command: ./configure --with-dpdk-lib=$RTE_SDK/$RTE_TARGET CFLAGS="-DMAX_CPUS=32" Please note that your NIC should support RSS queues equal to the MAX_CPUS value (since mTCP expects a one-to-one RSS queue to CPU binding). In case ./configure script prints an error, run the following command; and then re-do step-4 (configure again): autoreconf -ivf checksum offloading in the NIC is now ENABLED (by default)!!! this only works for dpdk at the moment use ./configure --with-dpdk-lib=$RTE_SDK/$RTE_TARGET --disable-hwcsum to disable checksum offloading. check libmtcp.a in mtcp/lib check header files in mtcp/include check example binary files in apps/example
Check the configurations in apps/example epserver.conf for server-side configuration epwget.conf for client-side configuration you may write your own configuration file for your application
Run the applications!
You can revert back all your changes by running the following script. ./setup_linux_env.sh [<path to $RTE_SDK>] Press [29] to unbind the Ethernet ports Press [30] to remove igb_uio.ko driver Press [33] to remove hugepage mappings Press [34] to quit the tool
make in io_engine/driver: make check ps_ixgbe.ko please note that psio only runs on linux-2.6.x kernels (linux-2.6.32 ~ linux-2.6.38)
install the driver: ./install.py <# cores> <# cores> refer to http://shader.kaist.edu/packetshader/io_engine/ you may need to change the ip address in install.py:46
Setup mtcp library: ./configure --with-psio-lib=<$path_to_ioengine> # e.g. ./configure --with-psio-lib=`echo $PWD`/io_engine make By default, mTCP assumes that there are 16 CPUs in your system. You can set the CPU limit, e.g. on a 8-core system, by using the following command: ./configure --with-psio-lib=`echo $PWD`/io_engine CFLAGS="-DMAX_CPUS=8" Please note that your NIC should support RSS queues equal to the MAX_CPUS value (since mTCP expects a one-to-one RSS queue to CPU binding). In case ./configure script prints an error, run the following command; and then re-do step-3 (configure again): autoreconf -ivf check libmtcp.a in mtcp/lib check header files in mtcp/include check example binary files in apps/example
Check the configurations in apps/example epserver.conf for server-side configuration epwget.conf for client-side configuration you may write your own configuration file for your application
Run the applications!
Install openNetVM following these instructions
Set up the dpdk interfaces: ./setup_mtcp_onvm_env.sh
Next bring the dpdk-registered interfaces up. This can be setup using: sudo ifconfig dpdk0 x.x.x.x netmask 255.255.255.0 up
Setup mtcp library ./configure --with-dpdk-lib=$<path_to_dpdk> --with-onvm-lib=$<path_to_onvm_lib> # e.g. ./configure --with-dpdk-lib=$RTE_SDK/$RTE_TARGET --with-onvm-lib=`echo $ONVM_HOME`/onvm make By default, mTCP assumes that there are 16 CPUs in your system. You can set the CPU limit, e.g. on a 32-core system, by using the following command: ./configure --with-dpdk-lib=$RTE_SDK/$RTE_TARGET --with-onvm-lib=$<path_to_onvm_lib> CFLAGS="-DMAX_CPUS=32" Please note that your NIC should support RSS queues equal to the MAX_CPUS value (since mTCP expects a one-to-one RSS queue to CPU binding). In case ./configure script prints an error, run the following command; and then re-do step-4 (configure again): autoreconf -ivf checksum offloading in the NIC is now ENABLED (by default)!!! this only works for dpdk at the moment use ./configure --with-dpdk-lib=$RTE_SDK/$RTE_TARGET --with-onvm-lib=$<path_to_onvm_lib> --disable-hwcsum to disable checksum offloading. check libmtcp.a in mtcp/lib check header files in mtcp/include check example binary files in apps/example
Check the configurations in apps/example epserver.conf for server-side configuration epwget.conf for client-side configuration you may write your own configuration file for your application
Run the applications!
You can revert back all your changes by running the following script. ./setup_linux_env.sh Press [29] to unbind the Ethernet ports Press [30] to remove igb_uio.ko driver Press [33] to remove hugepage mappings Press [34] to quit the tool
EAL: FATAL: Cannot init memory
Cannot mmap memory for rte_config at [0x7ffff7fb6000], got [0x7ffff7e74000] - please use '--base-virtaddr' option
EAL: Cannot mmap device resource file /sys/bus/pci/devices/0000:06:00.0/resource3 to address: 0x7ffff7ff1000

Support

You can optionally use CCP's congestion control implementation rather than mTCP's. You'll have wider selection of congestion control algorithms with CCP. (Currently this feature is experimental and under revision.). Using CCP for congestion control (disabled by default), requires the CCP library. If you would like to enable CCP, simply run configure script with --enable-ccp option.

Find more information at: