"m utku karatas" <m.utku.k@g_o_o_g_l_e_smailservice.com> wrote in message
news:Xns97EB280FC24903n523m3@207.105.83.66...
> I'm using TCP for my IPC needs. Currently I hit a bug where
> the client app hangs in a winsock Send function.
You are likely not managing the connection properly.
> This server has a thread for communication which is like
TIdTCPServer is already multi-threaded. Why are you using more threads thn
you need to? Inside the OnExecute event handler, you can do the following:
procedure TForm1.IdTCPServer1Execute(AThread: TIdPeerThread);
begin
fData :=
AThread.Connection.ReadString(AThread.Connection.ReadInteger(False));
AThread.Synchronize(Sync_OnReceivedData);
end;
> size := fSocket.ReadCardinal(False);
> fData := fRunSocket.ReadString(size);
Why are you reading from two different sockets? Or is that just a typo?
> void SendData(){
> ........
> sock.Send((char*)&size, sizeof(int)); // using my simple wrappers
> sock.Send(data.c_str(), size);
> }
You are sending an 'int' for the string length, but you are having the
server read a Cardinal instead. ReadString() can't take a Cardinal to begin
with. Notice above that I changed the reading code to receive an Integer
instead of a Cardinal.
> Till now I thought my primitive protocol is enough and bullet-proof
> but now I have this freeze situation in my client's(C++ one) "Send"
> winsock call(according to the debugger).
What is 'sock' declared as? What does Send() look like inside?
> I am told that the problem relates to TCP buffer but how is it possible
> that it gets full when the server is insistingly try to recv from the
> socket(see Delphi code above)?
There are several possibilities:
1) you are reading from two different socket object (unless that was just a
typo) in which case you are leaving data in the socket, which will then
cause the sender to block until the socket is emptied.
2) Sync_OnReceivedData() and/or Synchronize() has become blocked, so the
reading is blocked and the socket fills up with unread data.
> BTW what would you use to peek on this TCP buffer?
TCP does not (reliably) support peeking. In Indy's case, if the data has
already been read into TIdTCPConnection's InputBuffer, then you can peek the
data from that.
Gambit
