You are looking at doing something that is not normally done this particular way, not that you couldn't try it.
The issue is that most TCP/IP protocols are interactive to a command line, not a GUI. Hey, that won't stop you. It just makes life more difficult. I cannot do the best possible searches where I am because I am far from my home site. 'bout 580 miles from home.
Anyway, try to GOOGLE-search "PING" + "RFC" and see what articles have to say about the PING command. The RFC articles will describe some salient point about TCP or IP or both. Find an RFC article on PING and you'll learn more than you ever wanted to know about it.
The catch with PING is that, like most protocols, the response is not a STATUS CODE but is rather a text-like reply that will have to be captured and parsed out to see what your results were. Also, depending on your implementation of your protocol stack, PING might be unlimited. Therefore, when you build your commands, don't forget to limit the number of PING iterations.
You might look up the Shell function as a way to spawn a PING process and then trap the return. But there are many ways to skin a cat here. MMMMEEEEOOOOWWWWWRRRRRR
(Sorry, kitty!)