🚀 go-pugleaf

"SVC" <svchamlian@hotmail.com> schrieb im Newsbeitrag 
news:44b51e08@newsgroups.borland.com...
> 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
>>
>>
>
>