How to detect when a socket can be closed?

Question

I am printing to a thermal ticket printer which has no standard drivers. Traditionally our business process has been to produce a batch file of print items and to deliver that through an open socket to the printer. When the program has finished processing and prior to tidying up by shutting the socket I blocked the process by popping up a MessageBox with a warning to the user not to press OK until printing had finished: the next line of code then forcibly closed and cleared away the socket.

It was a bit of a sticky tape and string solution but it served its purpose.

I've recently overhauled the printing process using WCF Webservices and LINQ data management. As a result the batch files have become less necessary (they're still useful in the case of printing or reprinting for customers because the batchfile forms a sort of "receipt" to say that the physical ticket exists). But the old "stuff up a messagebox" solution to telling people when it's safe to close the socket looks unacceptably creaky in this new program.

So I want to have it just finish using the socket, exit gracefully and then pop up the box to say that printing is finished. Having a quick look around at possible solutions to this problem I have come across:

• The idea of using a separate thread for the printing process
• The idea of asynchronous sockets
• A method called Socket.Shutdown

What I'd really like is an overview of advantages/disadvantages of these three approaches.

Our usage scenario is that we seldom need use of a "queue" as the ticket printer isn't used anywhere near as heavily as a regular office printer. The printing of a batch of customer tickets or of 300 tickets for sale over the counter at a venue is still an event there aren't really disputes about who wants to do what and when. Even at one of our client sites where there are enough people that usage of the printer could cause conflicts the printer is usually closely monitored as it does its work.

This is, of course, because the minute a ticket comes out of the printer it has a monetary worth. As soon as the tickets are printed they tend to be taken away to be securely stored.

So bearing in mind this business process I want something unfussy that needn't worry overmuch about simultaneous requests.

EDIT: I did a bunch of research and tried different things on this. In this particular scenario the fact that the print socket blocks the UI thread is not a problem. People don't want to continue using the UI whilst the valuable stream of tickets streams out of the printer. But after looking at the way ASync requests work it seemed more logical given the most likely usage scenario to open the socket when the print options page opened and close it as it exited. The Async tutorials I did indicated that this is pretty much how things would work anyway.

Answer 1

• The idea of using a separate thread for the printing process: In this case you're still using sockets synchronously i presume. Which means you're still blocking the thread when awaiting a response. Which isn't a problem in a seperate thread, but performance wise it still isn't the way to go.

• The idea of asynchronous sockets: Is the standard way to use a socket when you don't want to block your current thread. This doesn't do any blocking operations which means better performance. The disadvantage is maybe that synchronous code looks a bit more clear and is easier to use. I would go with this one.

• A method called Socket.Shutdown: This isn't a solution to your problem. It is a way to disable sending and receiving on a socket. It is best practice to shutdown the socket before closing it. For example in C#:

  socket.Shutdown(SocketShutdown.Both); socket.Close();

Remember though when closing your application that you should wait until all backgound threads have been finished before actually letting the application close.