Mohammad Sami's suggestion is probably about the best you are going to be able to get.
The original TCP architecture does not have any way of detecting that a connection is lost, because the original architecture was designed to survive network outages, delivering the packet as soon as practical after the connectivity resumed. There are state variables involved, but the original model was either that it was not possible for the endpoints to go down or else the original model was that the endpoints would preserve all connection state when they went down and would resume it afterwards.
The original TCP archicture cannot distinguish between "I sent a packet to the other end and the packet got lost and I do not know it was lost and the other end does not know it was expecting a packet", compared to "I sent a packet to the other end which received it, but the other end has not chosen to reply yet." Accurately synchronizing state so that both sides are not only sure that a packet went through, but also that they are sure that the other end knows for sure that the packet went through, turns out to be a very hard problem in asychronous networks.
TCP also does not natively provide notification that the connection closed down smoothly, so unless you are acting as the TCP driver yourself, the way to detect that a connection has closed is to attempt an I/O operation and get told by the driver that the connection is closed.
But notice that that is about the connection being closed: the original architecture cannot tell whether the connection is "down" or if the other end just doesn't have anything to say to you. What does it mean for a connection to be "down" anyhow, when the entire IP architecture expects that there are multiple paths and expects that not all routes are available all the time? In a sufficiently connected network with appropriate routing protocols, you can turn off one of the intermediate routers and the network will route around the problem, finding the next best way to get packets to the destination. The loss of one router along the way does not mean that the connection is down; the loss of one packet along the way is defined as being acceptable, part of the architecture, routers are allowed to deliberately drop packets if they cannot keep up with the load. As far as TCP is concerned, the only sense in which a connection could be said to be "down" is if the endpoints go down (though in practice anything between the endpoints and the first redundant route is point of failure as well.)
Later add-ons to TCP added "keep-alives", which are periodic messages exchanged with no data; a pair of keep-alives exchanged between the endpoints gives information that the link is still alive. The convention is then that if too many of your keep-alives in a row go un-answered within a reasonable time, that you unilaterally declare the connection to be dead and attempt to close the connection; user I/O attempts would receive an error in this situation.
So... as a MATLAB programmer, you cannot get notified that a connection has gone down: all you can do is attempt an I/O operation and get told there was an error. You can then check the state of the connection to see if it indicates the connection is closed; if so then the link has been abandoned (rather than the other end simply being busy, for example.)