I really love the idea of uniqueinstance. I already downloaded the code and will probably add it to my project.
I just figured out that when i need that my server send one message to one client, it is never necessary to receive an answer, but when it is the client who sent the message, there must be always an anserw. But sometimes, the server could send a message to a client that already sent one request and is waiting for his answer yet. In those situations, the client will receive the server message and will think that is the answer... or not?
Example:
client.toServer.Writeln('What day is today?');
Client,Fromserver.Readln();
But due to connection delays, the server sends this to the client:
Server.ToClient.Writeln('Some rain expected for today');
and then answer the previous request...
Server.ToClient.Writeln('Tuesday');
If the client receives the line A before his answer it will crash.
Any fixes for this?
PS I will include a timer in the client to check if there are messages from the server.
Why is your server sending messages to clients when it has not been asked to? You have to take a consistent structured approach to your application's architecture here. In my opinion, the server should remain silent at all times until a client sends it a message. In my applications, the only exceptions to this are
a) a client is either connecting or disconnecting AND I need to notify other connected clients about this
b) the server is performing a database backup AND clients need to be notified that the server is busy (this backup is triggered by a server-side timer)
In those instances, the message is received client side by a popup tray message using the TPopupNotifier NEVER in the main client GUI. So I keep them separate
i) responses to client messages will be shown in the client side GUI
ii) server initiated messages will be shown in a TPopupNotifier
so there is no confusion between messages on the client side.
JD