🚀 go-pugleaf

"SVC" <svchamlian@hotmail.com> wrote in message
news:44b41065$1@newsgroups.borland.com...

> The problem is the receiving! Every time I call recv(...), it
> seems like the server (black box) is slowing down.

Reading from a socket, especially if you do it often, should not be slowing
the server down at all.  On the other hand, if you are not reading very
often, that could, especially if the server is using sockets in blocking
mode on its end.

> Is there a way to make solely the Receiving process event
> driven without altering the whole program?

You can use ioctlsocket() to put the socket into non-blocking mode.  But
keep in mind that doing so will greatly alter the behavior of your code.  If
your code is currently written to expect blocking operations, then you will
have to re-write it in order to handle the socket events.  Not only for
reading but for writing as well.  You need to use WSAAsyncSelect() or
WSAEventSelect() to receive the actual events, and the logic of your socket
management will be split up considerably because of the event handling.
When reading, you will have to buffer all incoming data, if you are not
already doing so, in order to ensure that you do not lose data between
events.  When writing, if the socket becomes blocked, then you have to wait
for an event to be triggered before you can write more data again.


Gambit

My socket is non-blocking though I have no idea of the server's socket mode
of operation.

Is it possible to use the  WSAAsyncSelect()  in a console application (i.e.,
no window handle available, my communication module is a thread running in
the background)?

S.



"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:44b424b9$1@newsgroups.borland.com...
>
> "SVC" <svchamlian@hotmail.com> wrote in message
> news:44b41065$1@newsgroups.borland.com...
>
> > The problem is the receiving! Every time I call recv(...), it
> > seems like the server (black box) is slowing down.
>
> Reading from a socket, especially if you do it often, should not be
slowing
> the server down at all.  On the other hand, if you are not reading very
> often, that could, especially if the server is using sockets in blocking
> mode on its end.
>
> > Is there a way to make solely the Receiving process event
> > driven without altering the whole program?
>
> You can use ioctlsocket() to put the socket into non-blocking mode.  But
> keep in mind that doing so will greatly alter the behavior of your code.
If
> your code is currently written to expect blocking operations, then you
will
> have to re-write it in order to handle the socket events.  Not only for
> reading but for writing as well.  You need to use WSAAsyncSelect() or
> WSAEventSelect() to receive the actual events, and the logic of your
socket
> management will be split up considerably because of the event handling.
> When reading, you will have to buffer all incoming data, if you are not
> already doing so, in order to ensure that you do not lose data between
> events.  When writing, if the socket becomes blocked, then you have to
wait
> for an event to be triggered before you can write more data again.
>
>
> Gambit
>
>

"SVC" <svchamlian@hotmail.com> wrote in message
news:44b51e08@newsgroups.borland.com...

> My socket is non-blocking

Sockets are blocking by default.  You have to explicitally put them into
non-blocking mode in your code.  You did not describe doing that step in the
sequence of operations that you posted earlier.

> Is it possible to use the  WSAAsyncSelect()  in a console application

Yes, but you will need to implement a message queue in your code in order
for it to work.  Non-blocking sockets are message-based objects, regardless
of whether you use a window or an event object to receive notifications of
socket events.

> my communication module is a thread running in the background

I do not recommend using a non-blocking socket in a worker thread if you can
avoid it.  That will complicate the thread's design.  Blocking sockets work
better.


Gambit