So is there a way to keep the client connection persistent and only 'close' when the client is finished?

In general, tcp connections are persistent. That is, they only disconnect when either the client or server explicitly choose to do so. However, there is usually an 'inactivity' timeout period, often set (for historical reasons) to 900 seconds, though that can be modified at either end of the connection.

If you have reason to believe that your client might not (naturally) use the connection frequently enough to prevent the inactivity timeout from kicking, then the usual thing to do is add a 'heartbeat' message to your protocol. This takes the form of a do-nothing message or exchange, that can be initiated from either the client or the server, at some regular period less than the prevailing timeout.

And if the connection is persistent, would that prevent other clients from connecting?

That depends upon the implementation of the server.

Well written servers -- whether selecting, pre-forking or threaded -- can easily maintain concurrent, persistent connections with many clients. Hundreds or even thousands of concurrent connections are possible for low-volume protocols, but it obviously depends upon the design and implementation of the server; the volume of traffic per client; the capacity of the server hardware; and the bandwidth of the servers network connections.

But that's all very general information. To get better answers to your questions you'll need to describe your application in more detail; and outline what problems you are either experiencing or are anticipate encountering.