The ntcpclient project offers a freely available replacement for tcpclient by ucspi-tcp, distributed under the GPL license. It provides similar features as the original tcpclient software.
I recently stumbled upon the ntcpclient project, a GPL replacement for tcpclient found in ucspi-tcp. After some prompting from a colleague utilizing the software in the bbots project, I decided to give it a try. As it turns out, it includes a sample echo client which may be of use to other individuals as well.
Although it is more primitive than the original ucspi-tcp version, I found it to be effective and easy to use. In truth, I admittedly did not use nor see the source of the program that ntcpclient replaced. This is because I initially believed the program to be closed source. However, it was a nice opportunity to write some code and become familiarized with ntcpclient.
The software operates through opening the socket and utilizing the options passed on the command line. This includes hostname lookups, among other tasks. It then proceeds by creating two pipes and forking. The parent process continuously selects on the socket/pipe, effectively relaying any data received between them. In contrast, the child executes the relevant command line, allowing the socket to be read or written to simply by writing to a numbered file descriptor. These file descriptors vary by system, but I found them to be consistently located at positions 5 and 6.
Overall, I was pleased with my experience utilizing ntcpclient. Although it may not have all the bells and whistles of ucspi-tcp, it was a reliable replacement and included helpful sample code.
Although it is more primitive than the original ucspi-tcp version, I found it to be effective and easy to use. In truth, I admittedly did not use nor see the source of the program that ntcpclient replaced. This is because I initially believed the program to be closed source. However, it was a nice opportunity to write some code and become familiarized with ntcpclient.
The software operates through opening the socket and utilizing the options passed on the command line. This includes hostname lookups, among other tasks. It then proceeds by creating two pipes and forking. The parent process continuously selects on the socket/pipe, effectively relaying any data received between them. In contrast, the child executes the relevant command line, allowing the socket to be read or written to simply by writing to a numbered file descriptor. These file descriptors vary by system, but I found them to be consistently located at positions 5 and 6.
Overall, I was pleased with my experience utilizing ntcpclient. Although it may not have all the bells and whistles of ucspi-tcp, it was a reliable replacement and included helpful sample code.
What's New