Best way for a Server to notify a Client it has initialised

Question

Edit 2 Renamed question

I have some Java code (the Client) which starts a separate process written in C# (the Server). The C# process is passed a pair of sockets (one to listen on, one to reply to); when it receives a connection on the listen socket, it processes the data sent and replies to the same IP on the reply socket. The process is designed to be running continuously, listening for connections and replying. Since it always replies to the same IP it can of course accept messages from many different clients. The Java code in turn listens to the process for its responses.

Although quite a basic system the setup is working perfectly except for one issue. The Java code determines whether the process is running or not before sending a message, using methods like Process.waitFor() and Process.exitValue() . The problem I have is that the process is not ready to actually receive messages for a few seconds after it starts.

My question is what is the best pattern to use for a server to tell a client it has started? The options I have thought of include:

1. The Java process repeatedly trying to connect and send a test message, only halting when response is received
2. The C# process broadcasts to a list of client IPs when it has started
3. The Java simply waits a few seconds and then tries to connect

I don't particularly like any of the above options, although I am leaning towards option 1). Is there any established pattern to use here?

Note that I do not want to use any existing framework for this communication. The actually messages are very simple, with the messaging code at both ends 'manually' encoding and decoding to a byte stream - for the sake of saving a hundred odd lines of code I don't wish to change this.

I realise this type of 'best way' question could be closed for being unconstructive, but I have googled for hours and come up with nothing. Any help or advice would be much appreciated :)

Edit - some more context

Although most client/server relationships involve the server starting long before any client tries to connect (thus avoiding this problem entirely), the setup here is slightly the different.

In this case, the client effectively starts the server as and when it needs it. In addition, if the client can see the server process isn't running it starts a new process. In both these cases the client needs to know when the server has initialised (not just when the process has started) before sending its first message

Answer 1

I would have one end act as a server. That server shouldn't start listening for new connections until it is ready to accept them eg it is initialised enough.

I would have the other end act as a client. The client shouldn't try to connect until it is ready to connect.

This way neither end needs to tell the other it is initialised because it shouldn't have a connection until both ends are initialised enough.

This one socket connection can be used to send messages one way as request and back the other way as replies. This can be either direction.

How would this handle multiple clients trying to connect to the same server? And what about asynchronous communication?

A server can have any number of connections. This is common practice.

I read somewhere that sharing a single socket means the communication has to be synchronous, but I could be wrong.

If you are using plain IO or NIO, the calls to write/read are synchronous. NIO2 mad the calls asynchronous IO (or something simulating it) but the extra complexity is not worth any advantage you might have IMHO.

If the server startup time is variable there is no way for the client to know that it should wait longer before connecting.

The client shouldn't need to know this. It can attempt to connect every N seconds until the server comes up.