Syncronizing between INDY TCP servers

Hi Alex, sorry not following you, yes both server controls use different ports, but the crux of the question is how do I ensure that Server 2 messages to Server 1's clients do not cause a corruption within server 1's own processing of its own clients requests

INDY 9 BTW

wel, the easiest way that does work is to use the good old process sincronization mechanisms: semaphores, mutex, etc.
say using critical section (this is  my favorite :D ) it would look something like this (the flow):

server1.clientX.cs.enter;// this locs clientx processing for server1
server1.clientX.process
server2.clientX.cs.enter;// this starts to wait for the resource to be abailable
server1.clientX.process
server1.clientX.process
server1.clientX.cs.leave;// not server2 kicks in
server2.clientX.process
server2.clientX.process
server2.clientX.cs.leave// server2 now finishes with it

same goes the other way around: if server2 gets to clientx faster than server1, then server1 will wait for server2 to finish

same thing is valid for mutex and cemaphores and whatever. of course using critical section process wide is a little trickier, and network wide is even more trickier unless ... you can simulate the same thing for network processes.

how to do that? it si rather simple: you will use a 3rd server (application) which can be installed on any of the 2 PCs. this will be the control app.

so what do you do?
- sever3 listens on port X
- one of server 1 or 2 will block access to client Y by connecting to server 3 and issuing a lock on client Y
- after finishing, it will unlock teh client by issueing an unlock on client Y
- when server 3 receives a lock on client Y it will try to lock it. if it's locked, it waits. if it's not, it locks it. how? using one of the process synchronization mechanisms I mentioned above :) (now we are talking about one process with multiple threads (one per each connection/lock))

unfortunatly a test code is not that fast to write (though it's easy) and it's 12:41 AM here.
but I will tell you the basics and you'll see that the method works.

so, a server will use a blocking socket and do seomthing like this:

socket.write("lock client x");
socket.read();// this will block until server3 responds with OK
process client x
socket.write("unlock client x");

it's that simepl on the 2 server side (1 and 2)

now on server 3:
in the onconnect event:
- create a new thread that will lock client sent on socket

- the trhead will
- client := socket.read(); // parse client number or ID
- cs[client].enter // try locking the client using critical section array or dinamic list
- socket.write("ok");
- socket.read()// this should be unclock client x, but we can ignore this, because according to our locking protocol defined, this is the only thing we can get. however, we can use an assert on the data sent just to be on the safe side
- cs[client].leave

hope it looks ok to you :)

ciuly, I think you are leading me in the right direction, however I cant put another server object on Client 1's program becauase I have no access to that program

Client one is polling the server so it already receives messages, but it seems it is loosing some or corrupting them because they are from differnet threads

to simplify matters imagine that I have a server app with just one tcp server. In this app there are 2 timers each firing at differnet intervals, when they fire I need to do a writeln to the client
both timers call the same bit of code , I have never used critical sections, but this looks like it could be the way, but how to implement?

procedure sendmsg(data: string);
begin
   TCPServer.Writeln(Data);
end;

presumably should change to

declare
  cs: TCriticalsection

procedure sendmsg(data: string);
begin
   if not Assigned(cs) then
    cs:=TCriticalSection.Create;
   cs.Acquire;
   TCPServer.Writeln(Data);
   cs.Release;
end;

procedure Timer1.OnTimer;
begin
  SendMsg('Something');
end;

procedure Timer2.OnTimer;
begin
  SendMsg('Something Else');
end;

Or is this wrong?

Ok will try

Main App has a number of TCPServer controls within it, these controls are connected to various clients, which I do not have control of

Client 1 sends a message to the server app, the server app acknoweldges receipt of that message, processes some data and then sends a reply to that client. Client 2 connects to a different TCPServer control within the same server app. This processes is own data, however it also needs to send data to Client 1.

So in pseudo

procedure TCPServer1.OnExecute;
begin
  TCPServer1.ReadLn;
  >>process data
  SendData1(Data);
end;

procedure TCPServer2.OnExecute;
begin
  TCPServer2.ReadLn;
  >>process data
  SendData2(Data);
  if x then
    SendData1(Data);
end;

prcoedure SendData1(Data: string);
begin
 TCPServer1.WriteLn(Data);
end;

prcoedure SendData2(Data: string);
begin
 TCPServer2.WriteLn(Data);
end;

Thus, this 'sending messages to the wrong client' seems to be a non-issue to me... Each server listens to it's own port and will use that port to communicate with the client. But let me get the situation clear...

You have one server executable. In it there are two server components. Both listen to different ports. Now, first of all there is the question of how many clients can be connected to both server components. Because if you're going to use a critical section then every client request will delay the execution of other client requests. So let's start with a simple code example: (Server code!)

type
  TForm1 = class(TForm)
    IdTCPServer1: TIdTCPServer;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure IdTCPServer1Execute(AThread: TIdPeerThread);
    procedure IdTCPServer2Execute(AThread: TIdPeerThread);
  private
    CS: TCriticalSection;
  public
  end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  CS := TCriticalSection.Create;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  CS.Free;
end;

procedure TForm1.IdTCPServer1Execute(AThread: TIdPeerThread);
begin
  CS.Enter;
  try
    Sleep(1000);
  finally CS.Release;
  end;
end;

procedure TForm1.IdTCPServer2Execute(AThread: TIdPeerThread);
begin
  CS.Enter;
  try
    Sleep(1000);
  finally CS.Release;
  end;
end;

If you use above code, however, you will have a big problem. As long as one of the two Execute methods is active, no other client requests will be processed and this will result in time-outs on very busy moments. (Or when the Execute performs some very slow code.) This is definitely NOT what you would like. Unless you only have one connected client...
Basically, what you would need is some indication that at least one thread is still active in it's execute method. For that a mutex would be a better solution. You would have something like this then:

const
  UniqueName = 'UniqueName';

procedure TForm1.IdTCPServer1Execute(AThread: TIdPeerThread);
var
  Mutex: THandle;
begin
  Mutex := CreateMutex(nil, false, UniqueName);
  try
    Sleep(1000);
  finally CloseHandle(Mutex);
  end;
end;

procedure TForm1.IdTCPServer2Execute(AThread: TIdPeerThread);
var
  Mutex: THandle;
begin
  CS.Enter;
  Mutex := CreateMutex(nil, false, UniqueName);
  try
    if (GetLastError = ERROR_ALREADY_EXISTS) then
    begin
      // Sorry, executing stuff now.
    end
    else
    begin
      Sleep(1000);
    end;
  finally CloseHandle(Mutex);
  end;
end;

Yet this approach has as disadvantage that Server2 will detect if one or more Execute methods of Server1 are running, yet it can't wait until they have all stopped processing. And when you want Server2 to send something back to all clients, you would need to prevent all Server1 clients from starting the Execute method. At least, until Server2 is done sending data. This will lead in even more synchronisation steps between the two server components. And it will make it extremely complex too.

So it seems to me that you might have to find an alternative approach. One solution might be the implementation of a stack, which stores the data from Server2 which must be sent to the clients of Server1. You would need a stack for every connected client, though. So when Server2 is executing, it puts the data that needs to be sent to thee Clients of Server1 to all the Client stacks. Then it's job is done. When Server1.execute is called, it checks the stack for the currently connected client and before (or after) it's regular actions it will send the data from the stack and remove it from the stack.
In that case, all you would need to synchronise is the access to the stack. Thus each client stack would need it's own critical section and two methods. (Say, Pop and Push.) The two methods just enter and leave the critical section when modifying the stack data.
The advantage of this is that you determine when data is sent to the client.

As an alternative solution, you could add a third server component. The clients who would connect to Server1 would then also have to connect to Server3. When Server2 needs to send data to the clients from Server1, it will send this data to the clients of Server3 instead. And Server3 will know what to do with it. This way you don't have one single TCP/IP stream which is used for two kinds of traffic...

that looks ugly and with a high posibility of errors unless the communication protocol is correctly defined and applications follow it. (like in case of the ftp)

so, in your case, at any given time, the server app must know exactly which clients are connected to the 2 server sockets and exactly when client1 expects the data preocessed for client2.

this is so very full of possible errors. you definitly need a solid protocol defined and clients to follow exactly the protocol. and the protocol must support waiting for data and such.

is this a proprietary protocol? can you post it?

Each server control only has 1 client attached

Well, if you only have one client connected to each, it seems quite simple to me. The critical section would work in that case. But then a stack will  be a simpler solution. Server2 would be pushing data to the stack and Server1 will pop it from the stack again. And the popped data is then send to the client, every time the client is polling Server1 for data.

That would be my solution, at least. But with only one client for each server it's a simple solution. Once you start having more than one client then you'll be in trouble.

Thanks for your comments guys, I appreciate the help

I now have code that sort of looks like he following

creator create;
begin
  FCS:=TCriticalSection.Create;
end;

procedure TCPServer1.Execute;
begin
  lz:=TCPServer1.ReadLn;
  --do stuff
  SendData(lp);
end;

procedure TCPServer2.Execute;
begin
  lz:=TCPServer2.ReadLn;
  --do stuff
  SendData(lp);
end;

procedure SendData(Data: string);
begin

end;

Sorry ignore last (misshit)

Thanks for your comments guys, I appreciate the help

I now have code that sort of looks like he following

creator create;
begin
  FCS:=TCriticalSection.Create;
end;

procedure TCPServer1.Execute;
begin
  lz:=TCPServer1.ReadLn;
  --do stuff
  SendData(lp);
end;

procedure TCPServer2.Execute;
begin
  lz:=TCPServer2.ReadLn;
  --do stuff
  SendData(lp);
end;

procedure SendData(Data: string);
begin
  CS.Acquire;
  try
    TCPServer1.Writeln(Data);
  finally
    CS.Realease;
  end;
end;




Comments please

Am asl toying with idea of using stack, one key problem that I need to allow for is that the external client is using Winsock not Indy

looks ok. but I still have some problem with the following possibilities (senddata called from servers):
1
2

or
2
1

will this behave correctly? because there is no way of telling which thread will get to senddata first.


>Am asl toying with idea of using stack, one key problem that I need to allow for is that the external
>client is using Winsock not Indy

that should not matter :)