Help with sockets..

[Sriram A Nandakumar]

Hi,

I have a requirement based on sockets and seem to be quite lost with the
options that I have on hand. Before I proceed here is my functional
requirement - I have a COM dll which will be contacting my server
application - not a service - but a plain application with a Server socket
in it (there could be multiple requests from clients at the same time). The
server receives this data and then does some processing - which might take
upto a minute max and then give back the result. Due to few reasons we plan
to stick to TServerSocket and TClientSocket itself.

What combination of sockets is best:

a) A Non blocking server and a Blocking client - On receiving text I create
a thread and pass the socket object to the thread and then start my
process.So if I receive 10 requests simultaneously, I create 10 threads.
However, there will be a Accept 'x' requests option. The sample test
application works okay. However, there was no way I could create a scenario
for data loss. On the client side I use a TWinSocketStream to send and read
data.

The issue found is if the server closes the connection then it works fine -
if the client closes the connection then it starts throwing up errors. Am I
missing anything here?
Also, if there is the network goes down, then TCustomWinSocket's (i really
wonder why this was done), WndProc method call Application.HandleException.
Since I create a thread for each request I could land up in a big mess with
all the windows opening up - otherwise too I donot want a error message
thrown and shown by the App.To resolve I inherited from TCustomWinSocket and
implemented the message handler - CM_SOCKETMESSAGE.
procedure CMSocketMessage(var Message: TCMSocketMessage); message
CM_SOCKETMESSAGE;
What i do is basically protect the method with try .. except and call
inherited. IS THIS OK?
This is what is created in the OnGetSocket event.
Note: I donot want to handle these in the Application.OnException :).

b) A Thread Blocking Server and a Blocking client - In the OnGetThread event
create a thread and allow the thread to take care from there. However, found
that at any one point of time only one connection can be active on a
particular port. The other requests gives a nasty 'Read Error 64'. I could
be wrong here though. In this case used TWinSocketStream both places. The
only problem in this case was the Read Error 64. I am quite confused with
what the help says 'the execution of the connection thread is suspended
while reading or writing until all information has been transferred over the
connection'. Does this mean a Thread blocking server will stop listening
until the connection on hand is complete?

In this method got stuck with Read error and so did not bother to try the
other issues that were found in type a).

Are there any other options available or should I go about doing the above
in the right way? Would be excellent if a sample application is made
available.

Help, suggestions highly appreciated.

Thanx in advance
Sri Ram

[Martin James]

Post by Sriram A Nandakumar
Hi,
I have a requirement based on sockets and seem to be quite lost with the
options that I have on hand. Before I proceed here is my functional
requirement - I have a COM dll which will be contacting my server
application - not a service - but a plain application with a Server socket
in it (there could be multiple requests from clients at the same time). The
server receives this data and then does some processing - which might take
upto a minute max and then give back the result. Due to few reasons we plan
to stick to TServerSocket and TClientSocket itself.
a) A Non blocking server and a Blocking client - On receiving text I create
a thread and pass the socket object to the thread and then start my
process.So if I receive 10 requests simultaneously, I create 10 threads.
However, there will be a Accept 'x' requests option. The sample test
application works okay. However, there was no way I could create a scenario
for data loss. On the client side I use a TWinSocketStream to send and read
data.
The issue found is if the server closes the connection then it works fine -
if the client closes the connection then it starts throwing up errors. Am I
missing anything here?
Also, if there is the network goes down, then TCustomWinSocket's (i really
wonder why this was done), WndProc method call

Application.HandleException.

Post by Sriram A Nandakumar
Since I create a thread for each request I could land up in a big mess with
all the windows opening up - otherwise too I donot want a error message
thrown and shown by the App.To resolve I inherited from TCustomWinSocket and
implemented the message handler - CM_SOCKETMESSAGE.
procedure CMSocketMessage(var Message: TCMSocketMessage); message
CM_SOCKETMESSAGE;
What i do is basically protect the method with try .. except and call
inherited. IS THIS OK?
This is what is created in the OnGetSocket event.
Note: I donot want to handle these in the Application.OnException :).

Sorry, I have never used non-blocking mode. It's just too much hassle.

Post by Sriram A Nandakumar
b) A Thread Blocking Server and a Blocking client - In the OnGetThread event
create a thread and allow the thread to take care from there. However, found
that at any one point of time only one connection can be active on a
particular port.

?? You can have many connections between a client machine/app and a server.
Sure, a seperate thread will be created for each one and a different port
allocated for each thread - does this matter?

The other requests gives a nasty 'Read Error 64'.

I have not seen this with TserverSocket in blocking mode.

I could

Post by Sriram A Nandakumar
be wrong here though. In this case used TWinSocketStream both places. Both

places?? You mean both client and server? I have to admit that I have not
used TwinSocketStream at a client end - I just create the TclientSocket in a
TThread & do socket reads.


The

Post by Sriram A Nandakumar
only problem in this case was the Read Error 64. I am quite confused with
what the help says 'the execution of the connection thread is suspended
while reading or writing until all information has been transferred over the
connection'. Does this mean a Thread blocking server will stop listening
until the connection on hand is complete?

Yes, and no. The listener thread always runs. When a connection request
arrrives at the listener socket, it runs the TCP connect protocol with the
client by calling 'accept'. This returns a socket for the new connection to
the client. This socket is passed to a serverClient thread, either in its
constructor or, if dequeued from a thread pool, directly into a thread field
before the dequeued, waiting thread is set running. The listener then loops
around to listen for new connections again. There is no problem with
multiple connections, either from a different client IP or from the same IP.

So, the listener will stop listening until 'the connection on hand is
complete', but this time is just as long as it takes to create/dequeue a
thread & pass the new socket. It is not relevant to the time a client stays
connected to its serverClient thread, which may be forever - the listneing
is independent.

Post by Sriram A Nandakumar
In this method got stuck with Read error and so did not bother to try the
other issues that were found in type a).

Thi should not happen. Have tou any code snippets from your serverClient
thread where you create the winSocketStream & do the reading?

Rgds,
Martin

[Sriram A Nandakumar]

Here is the server thread which process the client's request and using
TWinSocketStream --- Guess I am wrong here :)..

procedure TSocketRequestThread.ClientExecute;

function GetInputString: string;
var
objSocketStream: TWinSocketStream;
Buffer: array [0..1023] of char;
iBytesRead: integer;
begin
objSocketStream := TWinSocketStream.Create(ClientSocket, 10000);
try
Result := '';

repeat
FillChar(Buffer, SizeOf(Buffer), #0);
//
iBytesRead := 0;
try
iBytesRead := objSocketStream.Read(Buffer, Length(Buffer));
except
on E: Exception do
Result := Result + E.Message;
end;
if (iBytesRead > 0) then
Result := Result + Buffer;
until iBytesRead = 0;
finally
FreeAndNil(objSocketStream);
end;
end;

function ProcessInputString(AInputString: string): TRequestForm;
begin
if (AInputString <> '') then
begin
Result.EventHandle := CreateEvent(nil, True, False, nil);
Result.Port := ServerSocket.LocalPort;
Result.InputString := Between(AInputString, '<INPUTSTRING>',
'</INPUTSTRING>');
end;
end;

var
recReqForm: TRequestForm;
iBefore, iAfter: integer;
begin
try
while not Terminated and ClientSocket.Connected do
begin
iBefore := GetTickCount;
recReqForm := DoSomeThingHere(ProcessInputString(GetInputString),
CallBack);

WaitForSingleObject(recReqForm.EventHandle, 60000); { The request is
sent to the DoSomethingHere method which call another main execution thread
to process. On completion the event is signaled. }
//
iAfter := GetTickCount;

recReqForm.InputString := IntToStr(iBefore) + ' ' +
UpperCase(recReqForm.InputString) + IntToStr(iAfter) +
' Waiting time ' + IntToStr(iAfter - iBefore);

if ClientSocket.Connected then
begin
ClientSocket.SendText(recReqForm.InputString);
ClientSocket.Close;
Terminate;
end;
end;
except
end;
end;

Post by Sriram A Nandakumar

Post by Sriram A Nandakumar
Hi,
I have a requirement based on sockets and seem to be quite lost with the
options that I have on hand. Before I proceed here is my functional
requirement - I have a COM dll which will be contacting my server
application - not a service - but a plain application with a Server socket
in it (there could be multiple requests from clients at the same time).

The

Post by Sriram A Nandakumar
server receives this data and then does some processing - which might take
upto a minute max and then give back the result. Due to few reasons we

plan

Post by Sriram A Nandakumar
to stick to TServerSocket and TClientSocket itself.
a) A Non blocking server and a Blocking client - On receiving text I

create

Post by Sriram A Nandakumar
a thread and pass the socket object to the thread and then start my
process.So if I receive 10 requests simultaneously, I create 10 threads.
However, there will be a Accept 'x' requests option. The sample test
application works okay. However, there was no way I could create a

scenario

Post by Sriram A Nandakumar
for data loss. On the client side I use a TWinSocketStream to send and

read

Post by Sriram A Nandakumar
data.
The issue found is if the server closes the connection then it works

fine -

Post by Sriram A Nandakumar
if the client closes the connection then it starts throwing up errors.

Am

Post by Sriram A Nandakumar
I

Post by Sriram A Nandakumar
missing anything here?
Also, if there is the network goes down, then TCustomWinSocket's (i really
wonder why this was done), WndProc method call

Application.HandleException.

Post by Sriram A Nandakumar
Since I create a thread for each request I could land up in a big mess

with

Post by Sriram A Nandakumar
all the windows opening up - otherwise too I donot want a error message
thrown and shown by the App.To resolve I inherited from TCustomWinSocket

and

Post by Sriram A Nandakumar
implemented the message handler - CM_SOCKETMESSAGE.
procedure CMSocketMessage(var Message: TCMSocketMessage); message
CM_SOCKETMESSAGE;
What i do is basically protect the method with try .. except and call
inherited. IS THIS OK?
This is what is created in the OnGetSocket event.
Note: I donot want to handle these in the Application.OnException :).

Sorry, I have never used non-blocking mode. It's just too much hassle.

Post by Sriram A Nandakumar
b) A Thread Blocking Server and a Blocking client - In the OnGetThread

event

Post by Sriram A Nandakumar
create a thread and allow the thread to take care from there. However,

found

Post by Sriram A Nandakumar
that at any one point of time only one connection can be active on a
particular port.

?? You can have many connections between a client machine/app and a server.
Sure, a seperate thread will be created for each one and a different port
allocated for each thread - does this matter?
The other requests gives a nasty 'Read Error 64'.
I have not seen this with TserverSocket in blocking mode.
I could

Post by Sriram A Nandakumar
be wrong here though. In this case used TWinSocketStream both places. Both

places?? You mean both client and server? I have to admit that I have not
used TwinSocketStream at a client end - I just create the TclientSocket in a
TThread & do socket reads.
The

Post by Sriram A Nandakumar
only problem in this case was the Read Error 64. I am quite confused with
what the help says 'the execution of the connection thread is suspended
while reading or writing until all information has been transferred over

the

Post by Sriram A Nandakumar
connection'. Does this mean a Thread blocking server will stop listening
until the connection on hand is complete?

Yes, and no. The listener thread always runs. When a connection request
arrrives at the listener socket, it runs the TCP connect protocol with the
client by calling 'accept'. This returns a socket for the new connection to
the client. This socket is passed to a serverClient thread, either in its
constructor or, if dequeued from a thread pool, directly into a thread field
before the dequeued, waiting thread is set running. The listener then loops
around to listen for new connections again. There is no problem with
multiple connections, either from a different client IP or from the same IP.
So, the listener will stop listening until 'the connection on hand is
complete', but this time is just as long as it takes to create/dequeue a
thread & pass the new socket. It is not relevant to the time a client stays
connected to its serverClient thread, which may be forever - the listneing
is independent.

Post by Sriram A Nandakumar
In this method got stuck with Read error and so did not bother to try the
other issues that were found in type a).

Thi should not happen. Have tou any code snippets from your serverClient
thread where you create the winSocketStream & do the reading?
Rgds,
Martin

[Sriram A Nandakumar]

Thanks a ton Martin for taking time and assisting me with suggestions and
code.

I am tweaking the implementation keeping in mind your suggestions. I was
grossly confused again with WaitForData. My understanding of WaitForData
was - the socket is going to wait for timeout seconds or for message to flow
in - which ever is first. But then it does not work that way. What I did now
was on the server thread i just have this testing code to simulate the
actual working...

procedure TServerRequestThread.ClientExecute;
begin
FEventHandle := CreateEvent(nil, True, False, nil);

WaitForSingleObject(FEventHandle, 6000); {Just wait for six seconds to
simulate a work }
ClientSocket.SendText('Sending and waited for 6 seconds.. ');
ClientSocket.Close;
//
Terminate;
end;

and on the client side

procedure TDataRequestThread.Execute;
var
Buf: array [0..1023] of Char;
wsDataStream: TWinSocketStream;
begin
try
FClientSocket.ClientType := ctBlocking;
FClientSocket.Active := True;
FOutputData := 'Connected ';
wsDataStream := TWinSocketStream.Create(FClientSocket.Socket, 30000);
try
wsDataStream.Write(FInputData[1], Length(FInputData));

FOutputData := FOutputData + #13#10 + 'Reading ' + #13#10;
//
while (not Terminated) and (wsDataStream.WaitForData(60000)) do
-----------------------------------------> (a) }
begin
if (wsDataStream.Read(Buf, SizeOf(Buf)) <> 0) then
begin
FOutputData := FOutputData + Buf;
-----------------------------------------> (b) }
FillChar(Buf, SizeOf(Buf), #0);
end;
end;
finally
FreeAndNil(wsDataStream);
end;
except
on E: Exception do HandleThreadException(E);
end;
end;

I do a looping on the client side. It is not getting the reply back from the
server - it throws the error Read error 64 there at (b). The Outputdata I
get is Connected, Reading and Read Error 64.

// GUI Output
Connected
Reading
Sending and waited for 4 seconds.. w
Error Read error 64, The specified network name is no longer available
*
*
Connected
Reading

Error Read error 64, The specified network name is no longer available
*

I understand that READ gives me '0' in two cases -- i) When there is nothing
to read and ii) The connection is closed. As per your suggestion I do a
WaitForData before a Read in the loop- it returns me a 'True' - so the
connection is healthy it means - but call Read and it fails with Read Error
64.

I guess I will have to make my client Non blocking.. :).. Is Blocking type
used for a requirement of this kind where the client has to wait for
sometime for the reply....

Sri Ram

Post by Sriram A Nandakumar
Here is the server thread which process the client's request and using
TWinSocketStream --- Guess I am wrong here :)..

Yup, I'm sorry, but this will not work. First of all, you have to realise
that TCP is a streaming service. It has no concept of data starting and
finishing except on the byte/octet level. If you send a 256-byte buffer
from the client in one call, it can arrive in multiple segments of any

size

from one to 256 bytes. You seem to have some idea of this because you

are

attempting to loop around the read call, adding the returned buffer bytes

to

the string result each time until zero bytes are returned. IMHO, this

will

not work because you will have no way of differentiating a timeout, (ie.

end

of data) and a client close, (in which case read will also return zero).
You also have to wait ten seconds after the end-of-data to be sort-of-sure
that your client has finished sending stuff - can you really accept a
designed-in10-sec latency in your app?
To differentiate a timeout from client-disconnect, you have to use
waitForData. To promptly detect that your client has finished sending a
string, (lets call it an APDU), you have to analyse your protocol as the
bytes come in. As I read it, you are looking for a initial string of
'<INPUTSTRING>' and a terminating string of '</INPUTSTRING>'. To handle
this protocol in anything like a safe & efficient way, you have to do it
char-by-char from the input stream. Attempting to block-up the incoming
data into strings & then scanning the string using 'pos' etc. is grossly
inefficient and almost sure to lead to problems as bits of overlapping

APDUs

are received in multiple segments of varying size.
Your inter-thread comms using the event object probably works. The idea

is,

I guess, to hold up the thread until your APDU has been processed. If it
was me, I would be strongly tempted to dynamically create an object
containing the APDU, postMessage it off for processing & immediately
allocate another one in the thread, just in case another request came in.

I

understand that this will not happen in your case because your client will
wait for the result to be returned before continuing, but even so, it's

just

'nice' to seperate the received data and reply method from the actual
thread.
If you do anything like this, don't forget to free each APDU object in the
main thread after processing;
Rgds,
Martin
const
CstartString='<INPUTSTRING>';
CstopString= '</INPUTSTRING>';
type
Tscanner=class(Tobject)
private
scanString:TshortString;
scanIndex:integer;
public
constructor create(scanString:string);
function check(thisChar:char):boolean;
function len:integer;
end;
EprotoState=(psNotStarted,psExtracting)
Tapdu=class(Tobject);
private
startScanner,endScanner:Tscanner;
protoState:EprotoState;
outStr:Tstream;
public
APDUbuffer:array[0..maxRequestLen-1]of char;
buffLen:integer;
constructor create(start,stop:string;outStream:Tstream);
destructor destroy;
function add(inChar:char):boolean;
procedure reply(const replyStr:string);
end;
..
..
..
constructor Tscanner.create(inScanString:string);
begin
inherited create;
scanString:=inScanString;
scanIndex:=1;
end;
function Tscanner.len:integer;
begin
result:=length(scanString);
end;
function Tscanner.check(thisChar:char):boolean;
begin
result:=false;
if (thisChar=scanString[scanIndex]) then
begin
inc(scanIndex);
result:=(scanIndex=length(scanString));
if result then scanIndex:=1;
end
else
begin
scanIndex:=1;
if (thisChar=scanString[1]) then scanIndex:=2;
end;
end;
constructor Tapdu.create((start,stop:string);
begin
inherited create;
outStr:=outStream;
startScanner:=Tscanner.create(start);
endScanner:=Tscanner.create(stop);
buffLen:=0;
protoState:=psNotStarted;
end;
destructor Tapdu.destroy;
begin
startScanner.free;
endScanner.free;
inherited destroy;
end;
function Tapdu.add(inChar:char):boolean;
procedure checkForStart;
begin
if startScanner(inChar) then protoState:=psExtracting;
end;
procedure checkForEnd;
begin
result:=endScanner(inChar);
if result then
begin
buffLen:=buffLen-endScanner.len;
APDUbuffer[buffLen]:=#0;
end;
else
begin
APDUbuffer[buffLen]:=inChar;
inc(buffLen);
end;
end;
begin
result:=false;
case protoState of
psNotStarted:checkForStart;
psExtracting:checkForEnd;
end;
procedure Tapdu.reply(const replyStr:string);
begin
try
outStr.write(replyStr[1], length(replyStr));
except
end;
end;
procedure TSocketRequestThread.ClientExecute;
var thisAPDU:Tapdu;
objSocketStream: TWinSocketStream;
inBuff:array[0..1550] of char;
iBytesRead:integer;
charIndex:integer;
begin
try
objSocketStream := TWinSocketStream.Create(ClientSocket, timeout);
thisAPDU:=Tapdu.create(CstartString,CstopString,objSocketStream);
repeat
if objSocketStream.waitFor(timeout) then
begin
iBytesRead := objSocketStream.Read(inBuff,

Length(inBuff));

if (iBytesRead =0) then exit; // client disconnected
for charIndex:=0 to iBytesRead-1 do
begin
if thisAPDU.add(inBuff[charIndex]) then
begin
postMessage(mainFormHandle,WM_PROCESSAPDU,0,integer(thisAPDU));
thisAPDU:=Tapdu.create(CstartString,CstopString,objSocketStream);
end;
end;
end
else
begin
// timeout actions
end;
until terminated;
finally
thisAPDU.free;
objSocketStream.free;
end;

[Andy M.]

PMFJI...

Post by Sriram A Nandakumar
My understanding of WaitForData
was - the socket is going to wait for timeout seconds or for message to flow
in - which ever is first. But then it does not work that way.

It should work that way, and it does for me...
It is only a simple wrapper for winsock's select() which does return
as soon as data is available.

Post by Sriram A Nandakumar
begin
if (wsDataStream.Read(Buf, SizeOf(Buf)) <> 0) then

You have to save the result of Read because it is not guaranteed to
receive the exact amount you requested via SizeOf()

Post by Sriram A Nandakumar
FOutputData := FOutputData + Buf;

Here you have to make sure therefore, that you are not appending parts
of Buf that were not previously filled with data by Read.

Post by Sriram A Nandakumar
FillChar(Buf, SizeOf(Buf), #0);

This is not required then as well.

Post by Sriram A Nandakumar
I do a looping on the client side. It is not getting the reply back from the
server - it throws the error Read error 64 there at (b). The Outputdata I
get is Connected, Reading and Read Error 64.
// GUI Output
Connected
Reading
Sending and waited for 4 seconds.. w

In this case you already received everything + 2 garbage characters
left over in Buf.

Post by Sriram A Nandakumar
Error Read error 64, The specified network name is no longer available

Happens as soon as you call Read when the connection has already been
closed.

Post by Sriram A Nandakumar
I understand that READ gives me '0' in two cases -- i) When there is nothing
to read and ii) The connection is closed. As per your suggestion I do a
WaitForData before a Read in the loop- it returns me a 'True' - so the
connection is healthy it means - but call Read and it fails with Read Error
64.

Wrong!
Read will *only* give you 0 when the connection is closed.
When there's nothing to read, it will either block or return an error
(WSAEWOULDBLOCK) depending on the mode of the socket.
And WaitForData *will* return with True even if the following Read
call will return 0, because a Read call that returns 0 is to be
treated as successful by definition. Therefore WaitForData has to
return True as well.

Post by Sriram A Nandakumar
I guess I will have to make my client Non blocking.. :).. Is Blocking type
used for a requirement of this kind where the client has to wait for
sometime for the reply....

Use whatever suits you.
But there's no need to make it non-blocking.

Andy

[Sriram A Nandakumar]

Finally, broke the ice :). Thanks group for all the assistance. I was
missing on one thing which is the Serverclient Thread is created and starts
running as soon as the connection is accepted. Thought it to be helpful to
post for others who might fall in the same pit. A lot of helpful
tips/clarifications have been given by Martin and Andy.

However, in case of a Blocking server and a Blocking client - the
communication between the server and the client have to be in synch with
each other.

In the code (which was done for testing only) I had posted - I am waiting
for some time and then sending the data from server end - while the client
is sending some data first and waiting for data. Now in this case there is a
confusion between them mainly because the GetThreadEvent is triggered right
after the connection is accepted. So what is actually happening is the
client is busy sending data and the server sleeps and then starts sending
data and then 'closes' the connection. Now if the client is lucky then it
gets the data sent by the server before the connection is closed - if not
then it throws up the 'Read Error 64' in the read since the connection is
closed. That answers why WaitForData was not waiting for a minute - because
there was Data to be read and then the Read fails when the connection is
closed.

So in the process of streamlining the communication - now the server waits
for data to flow in and it considers that as a 'Command' then process the
command on similar line to what Martin had sent (however I just add a
character at the end of each command to say to the server socket that it is
end of command - not sure if it creates any problem - till now no issue
reported) and sends data back to the client who again processes it and then
sends a close command..

Finito..

phew.. I guess when I get some time I will work on few sample applications
involving all the varieties of connection and upload it somewhere - the chat
program that comes with delphi help is of absolutely no help at all...

Sri Ram

Post by Sriram A Nandakumar
Hi,
I have a requirement based on sockets and seem to be quite lost with the
options that I have on hand. Before I proceed here is my functional
requirement - I have a COM dll which will be contacting my server
application - not a service - but a plain application with a Server socket
in it (there could be multiple requests from clients at the same time). The
server receives this data and then does some processing - which might take
upto a minute max and then give back the result. Due to few reasons we plan
to stick to TServerSocket and TClientSocket itself.
a) A Non blocking server and a Blocking client - On receiving text I create
a thread and pass the socket object to the thread and then start my
process.So if I receive 10 requests simultaneously, I create 10 threads.
However, there will be a Accept 'x' requests option. The sample test
application works okay. However, there was no way I could create a scenario
for data loss. On the client side I use a TWinSocketStream to send and read
data.
The issue found is if the server closes the connection then it works fine -
if the client closes the connection then it starts throwing up errors. Am I
missing anything here?
Also, if there is the network goes down, then TCustomWinSocket's (i really
wonder why this was done), WndProc method call

Application.HandleException.

Post by Sriram A Nandakumar
Since I create a thread for each request I could land up in a big mess with
all the windows opening up - otherwise too I donot want a error message
thrown and shown by the App.To resolve I inherited from TCustomWinSocket and
implemented the message handler - CM_SOCKETMESSAGE.
procedure CMSocketMessage(var Message: TCMSocketMessage); message
CM_SOCKETMESSAGE;
What i do is basically protect the method with try .. except and call
inherited. IS THIS OK?
This is what is created in the OnGetSocket event.
Note: I donot want to handle these in the Application.OnException :).
b) A Thread Blocking Server and a Blocking client - In the OnGetThread event
create a thread and allow the thread to take care from there. However, found
that at any one point of time only one connection can be active on a
particular port. The other requests gives a nasty 'Read Error 64'. I could
be wrong here though. In this case used TWinSocketStream both places. The
only problem in this case was the Read Error 64. I am quite confused with
what the help says 'the execution of the connection thread is suspended
while reading or writing until all information has been transferred over the
connection'. Does this mean a Thread blocking server will stop listening
until the connection on hand is complete?
In this method got stuck with Read error and so did not bother to try the
other issues that were found in type a).
Are there any other options available or should I go about doing the above
in the right way? Would be excellent if a sample application is made
available.
Help, suggestions highly appreciated.
Thanx in advance
Sri Ram