stThreadBlocking Vs stNonBlocking confusion
Stefano Bonifazi
Maybe I should post this thread in the students forum as it's a basic
question ...
I always used "stNonBlocking" servers quite easily reading data from the
clients in the OnClientRead event handlers, and sending data to them
wherever I needed, without worrying about the OnClientWrite Event at all.
About "stThreadBlocking" I could get the following news:
From a tutorial on the borland site ( Creating a threaded socket server and
client application ) I see I should use the TWinSocketStream' and create my
own Threads and do all the stuff in the their ClientExecute method...
From the BCB Help I read: "The thread for each connection generates
OnClientRead or OnClientWrite events when the server socket needs to read or
write." so maybe I could continue to use the common OnClientRead for reading
being aware that many of those handlers could be executed at the same time,
so problems with "shared variables" could arise, while I should use the
OnClientWrite when I need to write to the clients.
Finally I learnt from a Mr Gambit's previous answer that I could easily
reuse the code of "stNonBlocking" servers with "stThreadBlocking" ones
calling Application->ProcessMessages() within the read loop (but what about
the sending stuff then?)
But my confusion starts from how they work and when I should use a
"stThreadBlocking" instead of "stNonBlocking" server.
On BCB Help I can read:
"When ServerType is stNonBlocking, all client connections are handled in a
single execution thread by default", but does not this mean that all other
sockets have to wait until the server finishes to execute the OnClientRead
of the current socket? If so why not this kind of server is called
"blocking" instead?
If I need a server that sends big files to many clients what kind of server
should I use?
If the server should send big files to few clients?
And many small packets to many clients?
Why should I use the threaded way for a TClientSocket? It has to manage only
one connection, so why to make it threaded? To lighten the program's main
thread burden?
I hope that here I can find someone able to answer to my doubts, cause all
books and articles I could find only increased my confusion :(
Thank You very much in advance!
Stefano B.
Remy Lebeau (TeamB)
"Stefano Bonifazi" <stefboo...@email.it> wrote in message
news:41fe...@newsgroups.borland.com...
> From a tutorial on the borland site ( Creating a threaded socket
> server and client application ) I see I should use the TWinSocketStream'
> and create my own Threads and do all the stuff in the their
> ClientExecute method...
That is one way to handle it.
> From the BCB Help I read: "The thread for each connection generates
> OnClientRead or OnClientWrite events when the server socket needs
> to read or write."
That is only true if you do not write your own thread class. The default
TServerClientThread.ClientExecute() implementation triggers the events. By
overriding ClientExecute() with your own implementation, you lose those
events unless you trigger them manually, which you usually don't need to do
if you are implementing ClientExecute() yourself anyway.
> I should use the OnClientWrite when I need to write to the clients.
That is not correct. Just like with non-blocking mode, OnClientWrite is
only used to indicate that a socket has become writable, not that you should
be doing all of your writing from there.
> Finally I learnt from a Mr Gambit's previous answer that I could easily
> reuse the code of "stNonBlocking" servers with "stThreadBlocking"
> ones calling Application->ProcessMessages() within the read loop
> (but what about the sending stuff then?)
I never said to use ProcessMessages() from a thread. I did say, however,
that non-blocking code could be written in a similar fashion to blocking
code, as long as you taking blocking situations into account properly.
> But my confusion starts from how they work and when I should
> use a "stThreadBlocking" instead of "stNonBlocking" server.
That is entirely up to you and your actual needs.
> "When ServerType is stNonBlocking, all client connections are handled
> in a single execution thread by default", but does not this mean that all
> other sockets have to wait until the server finishes to execute the
> OnClientRead of the current socket?
Yes.
> If so why not this kind of server is called "blocking" instead?
Because it is not blocking. "Blocking" vs. "non-blocking" refers to the
socket itself, not the server component managing the socket. In blocking
mode, socket operations "block" the calling code until the socket operation
is finished. In "non-blocking" mode, socket operations return control to
the calling code as soon as possible and then trigger asynchronous events
when the operations actually finish.
> If I need a server that sends big files to many clients what kind of
> server should I use?
It does not matter. Both modes can handle that, as long as you code for it
properly.
> If the server should send big files to few clients?
Again, the mode does not matter either way.
> And many small packets to many clients?
Again, the mode does not matter.
> Why should I use the threaded way for a TClientSocket?
Easier coding of the socket operations (your code does not have to be
separated amongst multiple event handlers), simultaneous processing of
multiple clients at a time, etc.
> To lighten the program's main thread burden?
That is another reason, yes.
Gambit
Stefano Bonifazi
"Remy Lebeau (TeamB)" <no....@no.spam.com> wrote in message
news:41fe99bf$1...@newsgroups.borland.com...
>> From the BCB Help I read: "The thread for each connection generates
>> OnClientRead or OnClientWrite events when the server socket needs
>> to read or write."
>
> That is only true if you do not write your own thread class. The default
> TServerClientThread.ClientExecute() implementation triggers the events.
> By
> overriding ClientExecute() with your own implementation, you lose those
> events unless you trigger them manually, which you usually don't need to
> do
> if you are implementing ClientExecute() yourself anyway.
>
Thank You now it takes a clear shape in my mind!:)
>> I should use the OnClientWrite when I need to write to the clients.
>
> That is not correct. Just like with non-blocking mode, OnClientWrite is
> only used to indicate that a socket has become writable, not that you
> should
> be doing all of your writing from there.
>
Great!! Thanks!! Now finally I understand what that event is needed for!:)
> I never said to use ProcessMessages() from a thread. I did say, however,
> that non-blocking code could be written in a similar fashion to blocking
> code, as long as you taking blocking situations into account properly.
>
Sorry my english was not clear, with thread I meant a newsgroup thread...
You wrote
>The easily way is to simply call Application->ProcessMessages() inside your
>loop whenever SendBuf() returns -1 so that OnWrite can be processed.
in "Re: Client: ctNonBlocking -> Server: stThreadBlocking" newsgroup thread
>> But my confusion starts from how they work and when I should
>> use a "stThreadBlocking" instead of "stNonBlocking" server.
>
> That is entirely up to you and your actual needs.
My needs are that the server can send or receive those big files at the same
time without one client sitting while waiting for others!
> Because it is not blocking. "Blocking" vs. "non-blocking" refers to the
> socket itself, not the server component managing the socket. In blocking
> mode, socket operations "block" the calling code until the socket
> operation
> is finished.
Sorry but I still don't understand :( What do You mean with calling code?
the process main thread? But if each socket connection gets its own thread
how can it block the main thread?
> In "non-blocking" mode, socket operations return control to
> the calling code as soon as possible and then trigger asynchronous events
> when the operations actually finish.
that is the OnClientRead is triggered once the socket has finished to
receive, Do I mistake? If so the block with "non-blocking" server is only
due on how I take to parse the arrived packets ...
>> Why should I use the threaded way for a TClientSocket?
>
> Easier coding of the socket operations (your code does not have to be
> separated amongst multiple event handlers), simultaneous processing of
> multiple clients at a time, etc.
>
I always thought that one of the most important features of BCB vs VC was
the clearness due to the events handlers ...
P.S. to Mr Gambit, You never answered a my problem about redirecting std
I/O, even if I think U know how to manage that, but I want tell You that I
actually solved that problem... I needed to Grant Session SID Access To the
current user's Winstation And Desktop to my process in order to get the
consolle redirected fine. A very advanced stuff for me, and of course I
could accomplish that only by reusing a code snipped from the net:-)
Hans Galema
> My needs are that the server can send or receive those big files at the same
> time without one client sitting while waiting for others!
A TServerSocket can receive big files simultanuously from many clients.
Both in blocking and non-blocking mode.
A TServerSocket can send big files simultanuously to many clients.
Both in blocking and non-blocking mode.
All things need programming.
> that is the OnClientRead is triggered once the socket has finished to
> receive, Do I mistake?
OnClientRead is triggered when the internal socket buffer is full
or when a certain time has elapsed. While your application reads
the data the socket can receive simultanuously.
>>>Why should I use the threaded way for a TClientSocket?
>>
>>Easier coding of the socket operations (your code does not have to be
>>separated amongst multiple event handlers), simultaneous processing of
>>multiple clients at a time, etc.
>>
> I always thought that one of the most important features of BCB vs VC was
> the clearness due to the events handlers ...
With this advise I disagree. One can just use OnRead for a non-blocking
TClientSocket. There is only one eventhandler: OnRead who decides
what has to be done. And of course there are no multiple clients at a time
for a TClientSocket. Advising what to use is difficult as it depends
on what the clientapplication does besides sending and receiving.
Hans.
Stefano Bonifazi
"Hans Galema" <not...@notused.nl> wrote in message
news:41ff691e$1...@newsgroups.borland.com...
> OnClientRead is triggered when the internal socket buffer is full
> or when a certain time has elapsed. While your application reads
> the data the socket can receive simultanuously.
>
Very clear now!!:) But let me recap:
- with non-blocking the server socket can receive simultaneously from many
clients, when one client dedicated buffer is full or when a certain time has
elapsed the OnClientRead is triggered, but as we have only one thread, only
one instance of this handler can run in the same time, so the other
clientsockets have to wait that we finish to process the data ALREADY stored
in the Socket buffer (that we can get through ReceiveText for example) and
exit the OnClientRead event handler
- with thread-Blocking multiple instances of the same OnClientRead event
handler can run at the same time, because of multiple threads, but inside
them we have to BLOCK the execution WHILE receiving the data
> With this advise I disagree.
Which advice do You refer to?
>One can just use OnRead for a non-blocking
> TClientSocket. There is only one eventhandler: OnRead who decides
> what has to be done. And of course there are no multiple clients at a time
> for a TClientSocket.
Really the threaded version of TClientSocket does not interest me much :)
... As U say only in the server we have multiple "clients" at the same time!
And if remember well I read somewhere in a previous Newsgroup thread that
the server has no idea of how the clients works ... so I should be able to
have a non-blocking Client and a ThreadBlocking server Do I mistake?
The problem is that with the simple test I'm posting in this thread right
now the Threadblocking server does nothing with my simple non-blocking
client...Please have a look to it if U have a little time :)
Advising what to use is difficult as it depends
> on what the clientapplication does besides sending and receiving.
You hit the point Mr. Galema ... ThankYou very much!
Stefano Bonifazi
test the threadblocking server ... of course they don't work (or better they
work if I set nonblocking for the server too!)
The Server application:
A simple TServerSocket with Active=true, port=1024,
ServerType=stThreadBlocking
A simple TMemo
void __fastcall TForm2::ServerSocket1ClientConnect(TObject *Sender,
TCustomWinSocket *Socket)
{
Memo1->Lines->Add("Client connected");
}
//---------------------------------------------------------------------------
void __fastcall TForm2::ServerSocket1ClientRead(TObject *Sender,
TCustomWinSocket *Socket)
{
Memo1->Lines->Add("Inside OnClientRead");
Application->ProcessMessages();
Memo1->Lines->Add("Client: "+Socket->ReceiveText());
Application->ProcessMessages();
Socket->SendText("Bye!");
}
//---------------------------------------------------------------------------
void __fastcall TForm2::ServerSocket1ClientWrite(TObject *Sender,
TCustomWinSocket *Socket)
{
Memo1->Lines->Add("OnClientWrite");
Socket->SendText("Bye!");
}
//---------------------------------------------------------------------------
void __fastcall TForm2::ServerSocket1ClientError(TObject *Sender,
TCustomWinSocket *Socket, TErrorEvent ErrorEvent, int &ErrorCode)
{
Memo1->Lines->Add("Error");
}
//---------------------------------------------------------------------------
It seems dead, nothing is written to the Memo :(
The Client Application:
A simple TClientSocket with Port=1024, Address=127.0.0.1, Active=false,
ClientType=ctNonBlocking
A simple TMemo, A TStatusBar, 2 TButtons
void __fastcall TForm1::Button2Click(TObject *Sender)
{
ClientSocket1->Active=true;
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
if(ClientSocket1->Socket->Connected)
ClientSocket1->Socket->SendText(Edit1->Text);
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ClientSocket1Connect(TObject *Sender,
TCustomWinSocket *Socket)
{
StatusBar1->SimpleText="Connected";
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ClientSocket1Read(TObject *Sender,
TCustomWinSocket *Socket)
{
Memo1->Lines->Add("Server: "+Socket->ReceiveText());
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ClientSocket1Error(TObject *Sender,
TCustomWinSocket *Socket, TErrorEvent ErrorEvent, int &ErrorCode)
{
StatusBar1->SimpleText="Error";
}
//---------------------------------------------------------------------------
After I've clicked Button2, I can see that the OnConnect event handler has
been executed, but if then I click the Button1 nothing happens! :(
Where do I mistake? It's so discouraging when after so much study, even so
simple test does not run ;(
Thank You all for Your help!
Stefano b.
Remy Lebeau (TeamB)
> Great!! Thanks!! Now finally I understand what that event is needed for!:)
Well, there is a caveat to the OnWrite events - if you make a blocking call
on a non-blocking socket, the call will fail with a WSAEWOULDBLOCK error
code, and you have to wait until the OnWrite event is triggered before you
can send more data to the socket again.
> My needs are that the server can send or receive those big files
> at the same time without one client sitting while waiting for others!
That is not what I meant. I was referring to the requirements of the server
(how many clients it should service, what kind of application you are using
the code in, etc).
> Sorry but I still don't understand :( What do You mean with calling code?
The code that is calling SendBuf(), ReceiveBuf(), etc. In other words, the
code that is sending/reading the data to/from the socket.
> that is the OnClientRead is triggered once the socket has finished
> to receive, Do I mistake?
OnClientRead is triggered when data has arrived on the socket but has not
been read by the application yet..
> I always thought that one of the most important features of BCB
> vs VC was the clearness due to the events handlers ...
Setting up event handlers in general is clean. Actually using events to
control your processing can break up your code logic and make it difficult
to manage and/or debug.
Gambit
Remy Lebeau (TeamB)
> void __fastcall TForm2::ServerSocket1ClientConnect(TObject *Sender,
> TCustomWinSocket *Socket)
> {
> Memo1->Lines->Add("Client connected");
> }
You cannot do that. In blocking mode, the server uses a separate worker
thread to listen for incoming connections. The OnConnect event is triggered
in the context of that thread, not the main thread. The VCL is not
thread-safe in general, and as such accessing the GUI directly from a worker
thread can be dangerous. You must synchronize access to the GUI so that the
code accessing the GUI is executed in the context of the main thread only.
> void __fastcall TForm2::ServerSocket1ClientRead(TObject *Sender,
> TCustomWinSocket *Socket)
> {
> Memo1->Lines->Add("Inside OnClientRead");
> Application->ProcessMessages();
> Memo1->Lines->Add("Client: "+Socket->ReceiveText());
> Application->ProcessMessages();
> Socket->SendText("Bye!");
> }
Same here. You are accessing the GUI in an unsafe manner, because
OnClientRead is going to be triggered in the context of a worker thread, not
the main thread. Not only that, but you should never call ProcessMessages()
from the events of a blocking server, either.
> void __fastcall TForm2::ServerSocket1ClientWrite(TObject *Sender,
> TCustomWinSocket *Socket)
> {
> Memo1->Lines->Add("OnClientWrite");
> Socket->SendText("Bye!");
> }
You don't need to use the OnClientWrite event with a blocking server.
> void __fastcall TForm2::ServerSocket1ClientError(TObject *Sender,
> TCustomWinSocket *Socket, TErrorEvent ErrorEvent, int &ErrorCode)
> {
> Memo1->Lines->Add("Error");
> }
Still accessing the GUI in an unsafe manner.
> It seems dead, nothing is written to the Memo :(
That is what happens when you do not access the GUI in a thread-safe manner.
Gambit
Remy Lebeau (TeamB)
> - with non-blocking the server socket can receive simultaneously
> from many clients
The server can do that regardless of blocking or non-blocking.
> when one client dedicated buffer is full or when a certain time has
> elapsed the OnClientRead is triggered, but as we have only one
> thread, only one instance of this handler can run in the same time
Yes. However, the data in the socket is already buffered in memory by the
time the OnClientRead event is triggered. You can query how many data is
actually available via ReceiveLength() and then perform a single read to
copy the entire buffer into your application's own buffers in a single
operation very quickly. If your processing of the data is simple, the event
handler will exit relatively quickly, and other sockets can then be serviced
just as quickly. If, on the other hand, your processing of the data can be
time-consuming, then you should copy the data to a different thread so that
the event handler can exit as soon as possible.
> - with thread-Blocking multiple instances of the same OnClientRead
> event handler can run at the same time, because of multiple threads,
> but inside them we have to BLOCK the execution WHILE receiving the data
A thread that is reading from a blocking socket doesn't need to do anything
else while it is reading, so blocking the thread is fine.
> I should be able to have a non-blocking Client and a ThreadBlocking server
Correct.
> The problem is that with the simple test I'm posting in this thread right
> now the Threadblocking server does nothing with my simple non-blocking
> client...
You are probably not using it correctly.
Gambit
Stefano Bonifazi
>
Thanks Remy once more time! :-)
>> - with non-blocking the server socket can receive simultaneously
>> from many clients
>
> The server can do that regardless of blocking or non-blocking.
>
Good!
> Yes. However, the data in the socket is already buffered in memory by the
> time the OnClientRead event is triggered. You can query how many data is
> actually available via ReceiveLength() and then perform a single read to
> copy the entire buffer into your application's own buffers in a single
> operation very quickly. If your processing of the data is simple, the
> event
> handler will exit relatively quickly, and other sockets can then be
> serviced
> just as quickly. If, on the other hand, your processing of the data can
> be
> time-consuming, then you should copy the data to a different thread so
> that
> the event handler can exit as soon as possible.
Great! That's music for my ears!
> A thread that is reading from a blocking socket doesn't need to do
> anything
> else while it is reading, so blocking the thread is fine.
Fine! So I guess that in non blocking mode Borland or Microsoft have their
"threads" setting " while receiving from the different clients!
>> I should be able to have a non-blocking Client and a ThreadBlocking
>> server
>
> Correct.
>
GOOOD New!!
>> The problem is that with the simple test I'm posting in this thread right
>> now the Threadblocking server does nothing with my simple non-blocking
>> client...
>
> You are probably not using it correctly.
OK but the main problem is that even if I searched all google as You
suggested I only could find examples of Threadblocking ServerSocket using
the user made Threads with TWinSocketStream, nothing using the common
OnClientRead event! :(
Thanks again Gambit! Have You never thought to take a University seat? I
would pay gold to have such a teacher!:)
Stefano Bonifazi
I must thank You once more, but I have to ask again for a pleasure too :(
The problem is that even if I searched all google as You suggested I only
could find examples of Threadblocking ServerSocket using the user made
Threads with TWinSocketStream, nothing using the common OnClientRead event!
:(
I have even bought a very expensive book C++B 5 dev's guide, but it even
does not speak about ThreadBlocking servers :(
Could you be so kind to correct my VERY simple project in order to make it
work fine?
Thank you anyway in advance!
Stefano B.
Stefano Bonifazi
"Remy Lebeau (TeamB)" <no....@no.spam.com> ha scritto nel messaggio
news:41ffd045$1...@newsgroups.borland.com...
>
> Well, there is a caveat to the OnWrite events - if you make a blocking
> call
> on a non-blocking socket,
Which for instance?
>the call will fail with a WSAEWOULDBLOCK error
> code, and you have to wait until the OnWrite event is triggered before you
> can send more data to the socket again.
May I use Application->ProcessMessages() instead?
>> My needs are that the server can send or receive those big files
>> at the same time without one client sitting while waiting for others!
>
> That is not what I meant. I was referring to the requirements of the
> server
> (how many clients it should service, what kind of application you are
> using
> the code in, etc).
My server has to support many clients (not more than a hundred though!), and
it's application have only to store what it receive or at least re-send that
>> Sorry but I still don't understand :( What do You mean with calling code?
>
> The code that is calling SendBuf(), ReceiveBuf(), etc. In other words,
> the
> code that is sending/reading the data to/from the socket.
>
As You said in the other message that thread code only have to receive /
send the data, so it does not matter if it has to wait ... the program main
thread is free to do whatever meanwhile!:)
Thanks Gambit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Hans Galema
> Could you be so kind to correct my VERY simple project in order to make it
> work fine?
Did not you start yet with:
Tutorial for creating a threaded socket server and client application
- by Borland Developer Support Staff
http://bdn.borland.com/article/0,1410,26276,00.html.tutorial.html
Be sure to read the 'Add or View comments' at the bottom of the page.
Hans.
Remy Lebeau (TeamB)
> The problem is that even if I searched all google as You suggested I
> only could find examples of Threadblocking ServerSocket using the
> user made Threads with TWinSocketStream, nothing using the common
> OnClientRead event!
It is much easier and linear to code for ClientExecute() rather then
OnClientRead. You can keep your processing localized rather than spread out
Gambit
Remy Lebeau (TeamB)
> Fine! So I guess that in non blocking mode Borland or Microsoft
> have their "threads" setting " while receiving from the different clients!
Huh?
> OK but the main problem is that even if I searched all google as
> You suggested I only could find examples of Threadblocking
> ServerSocket using the user made Threads with TWinSocketStream,
> nothing using the common OnClientRead event! :(
It is much easier and linear to code for ClientExecute() rather then
Steve Aletto
> The problem is that even if I searched all google as You
> suggested I only could find examples of Threadblocking
> ServerSocket using the user made Threads with
> TWinSocketStream, nothing using the common OnClientRead event!
Because it's the best way to handle sockets inside a thread.
Forget socket events if you're using sockets inside a thread.
> I have even bought a very expensive book C++B 5 dev's guide,
> but it even does not speak about ThreadBlocking servers :(
You're right. Very good book, but not many information about
sockets.
> Could you be so kind to correct my VERY simple project in
> order to make it work fine?
Please follow Hans's suggestion and have a look at the Borland
tutorial. Your project surely doesn't work, setting
ServerType=stThreadBlocking is not enough at all to handle a
thread-blocking socket! Where's the thread to begin with?
HTH,
Steve.
Stefano Bonifazi
>> Fine! So I guess that in non blocking mode Borland or Microsoft
>> have their "threads" setting " while receiving from the different
>> clients!
>
> Huh?
"hidden threads" that receive the data and the give it us through the
OnClientRead event ... I don't now if it's done in TServerSocket or in the
Microsoft Socket behind it
It is much easier and linear to code for ClientExecute() rather then
> OnClientRead. You can keep your processing localized rather than spread
> out
I'm sure You, from the height of Your great experience, are right once more,
but I'm here as a student eager to learn all the possible ways :)
Thanks again!
Stefano Bonifazi
As said in the other message:
I'm here as a student eager to learn all the possible ways :-)
"Remy Lebeau (TeamB)" <no....@no.spam.com> ha scritto nel messaggio
news:4200...@newsgroups.borland.com...
Stefano Bonifazi
but I would like to implement the OnClientRead way to do a ThreadBlocking
TServerSocket!!! According Borland Help it may be possible... I only can't
find a simple code snippet :(
I'd already read that article!
"Hans Galema" <not...@notused.nl> ha scritto nel messaggio
news:4200...@newsgroups.borland.com...
Stefano Bonifazi
> Because it's the best way to handle sockets inside a thread. Forget socket
> events if you're using sockets inside a thread.
As I told to Mr. Lebeau:
I'm here as a student eager to learn all the possible ways :)
>
>> I have even bought a very expensive book C++B 5 dev's guide, but it even
>> does not speak about ThreadBlocking servers :(
> You're right. Very good book, but not many information about sockets.
You arrive @ the right time:)
I've found on the net that now it's available C++B. 6 dev's guide ... It's a
very expensive book, but I think that knowledge has no prize even for a
money less student:-)
I was thinking though that it's a lot of time since BCB 6 has been released
... so my question is should I wait the new BCB 7 and so C++B. 7 dev's
guide? Is BCB7 upcoming?
Best regards,
Stefano B.
Hans Galema
> Thank You Mr. Hans,
> but I would like to implement the OnClientRead way to do a ThreadBlocking
> TServerSocket!!! According Borland Help it may be possible... I only can't
> find a simple code snippet :(
> I'd already read that article!
Why would you do it like that? It brings nothing.
Hans.
Remy Lebeau (TeamB)
> I mean that TServerSocket when acts as "nonblocking" should
> have some "hidden threads" that receive the data and the give it
> us through the OnClientRead event ...
That is not correct. Threads are not used in non-blocking mode. Events are
triggered using window messages that are posted by the socket stack instead.
Gambit
Remy Lebeau (TeamB)
> but I would like to implement the OnClientRead way to do a
> ThreadBlocking TServerSocket!!! According Borland Help it
> may be possible... I only can't find a simple code snippet :(
Coding for OnClientRead is exactly the same in both non-blocking and
blocking mode, with the exception that you need to use a TWinSocketStream to
access a blocking socket.
Gambit
Remy Lebeau (TeamB)
> Is BCB7 upcoming?
Please have a look in the non-technical newsgroups, there are tones of
discussions about that lately.
Gambit
Stefano Bonifazi
You're knowledge is amazing!
My best regards,
Stefano B.
"Remy Lebeau (TeamB)" <no....@no.spam.com> ha scritto nel messaggio
news:42013510$1...@newsgroups.borland.com...
Stefano Bonifazi
"Hans Galema" <not...@notused.nl> wrote in message
news:4200fd0d$1...@newsgroups.borland.com...
As said in the other message to Mr. Lebeau:
I'm here as a student eager to learn all the possible ways :-)
.
Stefano Bonifazi
> Coding for OnClientRead is exactly the same in both non-blocking and
> blocking mode, with the exception that you need to use a TWinSocketStream
> to
> access a blocking socket.
I'm sorry to say that's the sort of answers I hate ...
As an engineering student I think that is better a simple but implemented
project than 1000 good papers ... Is so difficult to post not more than 10
line of working code?
I think it would be great for future newsgroup searches too :)
Anyway You'll always deserve my best and sincere gratitude :)
Stefano B.
"Remy Lebeau (TeamB)" <no....@no.spam.com> ha scritto nel messaggio
news:42013551$1...@newsgroups.borland.com...
>
> "Stefano Bonifazi" <stefboo...@email.it> wrote in message
> news:4200...@newsgroups.borland.com...
>
>> but I would like to implement the OnClientRead way to do a
>> ThreadBlocking TServerSocket!!! According Borland Help it
>> may be possible... I only can't find a simple code snippet :(
>
>
>
> Gambit
>
>
Stefano Bonifazi
... in only my studies left me the time to pass more time on them ...
"Remy Lebeau (TeamB)" <no....@no.spam.com> ha scritto nel messaggio
news:4201...@newsgroups.borland.com...
Hans Galema
> I'm sorry to say that's the sort of answers I hate ...
> As an engineering student I think that is better a simple but implemented
> project than 1000 good papers ... Is so difficult to post not more than 10
> line of working code?
> I think it would be great for future newsgroup searches too :)
It would be nice if such an eager engineering student as you are would
combine all the knowledge he got here or can find here and then apply
some imagination on a slightly different approach that only he wanted.
So please produce those ten lines of code yourself as a nice exercise.
Would be great for future newsgroup searches too ;-)
Hans.
Chad Z. Hower aka Kudzu
@newsgroups.borland.com:
> project than 1000 good papers ... Is so difficult to post not more than
> I think it would be great for future newsgroup searches too :)
he he. If only more users would search. :)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Want more Indy stuff? Try the Atozed Indy Portal at
http://www.atozedsoftware.com/
* More Free Demos
* Free Articles
* Extra Support
Remy Lebeau (TeamB)
> Is so difficult to post not more than 10 line of working code?
Please go to http://www.deja.com and browse/search through the archives for
these newsgroups. Tons of sample code have already been posted in the past.
Gambit