the following is my codes:
/*
return value:
0 : got len bytes in buf successfully
-1: error when receiving data from socket
*/
int myrcv(int fd,int len,char* buf)
{
int n=0;
//peeking whether having n bytes available
while (n <len)
{
n=recv(fd,buf,len,MSG_PEEK);
if(n<len) sleep(1);
}
n=read(fd,buf,len);
if(n!=len)
{
return -1;
}
return 0;
}
are there bugs in my codes ? or anything wrong ?
thank you .
You do not check for errors here.
> }
> n=read(fd,buf,len);
> if(n!=len)
> {
> return -1;
> }
> return 0;
> }
>
> are there bugs in my codes ? or anything wrong ?
> thank you .
Why do you want to use MSG_PEEK? It will not make the code faster;
the sleep() can make it thousands of times slower. If you are going
to sleep, you might as well sleep in a recv() call.
Since you do not want to return until you have len bytes or an error,
why not just call recv() repeatedly, adding to your buf until it is
full? I assume this is a TCP socket in blocking mode.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
buf buf+len
............
read ......
read .......................
read ..
read, and done!
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
*That* is a much clearer question. Thanks!
I'm not sure, but one of the experts will probably answer.
I personally do not want to know, because I think using
MSG_PEEK is a sign of a bad design. There is usually a
better way of solving the problem (whatever the problem is).
No, you cannot do that. This has to be prohibited because if everyone
did it, nothing would work.
Consider:
Side A has 100 bytes to send side B. But it decide to only send it one
byte. (Heck, why not?)
You peek at the one byte and think "hey, I'll wait for more bytes".
(Heck, why not?)
The other side elects not to send any more data until you accept the
byte it has already sent. (Heck, why not?)
Deadlock.
So there are two ways to solve this:
1) You could have a rule that the sender can never refuse to send data
just because the other side has not completed receiving data. But this
is a disaster as it requires unlimited in flight data.
2) You could have a rule that a receiver can never refuse to read/
accept data just because the other side has not completed sending
data. This is not a disaster, so this is the rule we have.
You are asking "can I violate this rule". The answer is, no, because
if everyone violated all the rules, nothing would work. You will
likely get away with it, because everyone else is probably following
the rules.
It's kind of like not paying taxes. You won't bankrupt the government
so long as everyone else pays taxes. But officially, it must be
prohibited because if everyone did it, nothing would work.
DS
[...]
> It's kind of like not paying taxes. You won't bankrupt the government
> so long as everyone else pays taxes. But officially, it must be
> prohibited because if everyone did it, nothing would work.
That is an *excellent* metaphor to explain why "playing by the rules" is
important. Expect to be quoted frequently!
Many thanks.
- Philip
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
"You see a wile, you thwart. Am I right?"
-- Crowley the demon and Aziraphale the angel in conversation
(Terry Pratchett & Neil Gaiman, Good Omens)