On Oct 25 15:06, Marcell Missura wrote:
> I also find it weird that after an
> error occured select() returns and tells you that the socket has something
> to _read_.
That's documented standard behaviour. I pointed this out in my first
reply. If you're still learning socket programming I'd like
> Maybe you were also a little quick with your code. You don't really
> test what's going on, so your code is going crazy.
It demonstrates the difference in the behaviour of this select(),
recvfrom(), send() construct under linux and windows fairly well doesn't
it. I apologize if my unsophisticate
On Oct 24 19:31, Marcell Missura wrote:
> Hi,
>
> actually you were right, I was a bit too quick with my extract. It didn't
> contain an important line. I'm also sending out stuff through that socket.
> So here it goes, you can copy paste and compile this.
Maybe you were also a little quick with
Hi,
actually you were right, I was a bit too quick with my extract. It didn't
contain an important line. I'm also sending out stuff through that socket.
So here it goes, you can copy paste and compile this.
#include
#include
#include
#include
#include
#include
#include
#include
#include
On Oct 24 17:12, Marcell Missura wrote:
> Hello,
>
> I observed some strange behaviour on Windows when I was using a select()
> and recvfrom() combination to implement a socket listening behaviour with
> timeout. Here is an extract from a test program.
> [...]
> First of all, you might notice that
Hello,
I observed some strange behaviour on Windows when I was using a select()
and recvfrom() combination to implement a socket listening behaviour with
timeout. Here is an extract from a test program.
struct timeval tv;
while(1)
{
tv.tv_sec = 0;
tv.tv_usec = 0.001*100;
// The ac
6 matches
Mail list logo
