Re: Socket differences between localhost and LAN (or Internet)

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

"Wyvern" <davinator17@xxxxxxxxxxx> wrote in message
news:1158053516.079312.40190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Wait wait wait Will,

:-)

I need to focus on two things:

Recv() is not reliable , ok, is the Send() reliable too ?

:-) Recv() is reliable.

IMO, you should do more reading and less trying to convince others of the
correctness of your position.

And then, let's assume that I have received some data with Recv(), but
I see that the total amount of received bytes is not what I expected,
what I have to do ?

As I have said two or three times now - you keep calling recv().

Clear the buffer and ask a retransmission to the
server UNTIL I got the exact amount of bytes ?

No, of course not.

Because what i do not understand now is this :

When you launch the command:

...
bytes_recv=Recv();
...

bytes_recv cannot be the exact number of bytes that have been really
sent, but what happens ?

The other bytes of the transmission are in transit. They can be anywhere
along the path from sender to receiver.

The Recv() has returned a number, and the
program proceeds on its way, why is Recv()
so stupid to return a value even if it is not
the complete amount of bytes received ?

recv() is not stupid. It's quite smart. What you don't understand is that
TCP operates in a "packet-switched" mode. You may choose to send a full
megabyte if you like but there are constraints that prevent the send from
happening in one transmission. IIRC, for example, when using IP over
ethernet the maximum size of a block that can be transmitted at the hardware
level is around 1.5KB. As the chunks are received at the other side, one or
more calls to recv() complete.

Frankly, you have more work to do than you know. Take a look at the help
entry for the send() function

<quote>
If no error occurs, send returns the total number of bytes sent, which can
be less than the number indicated by len. Otherwise, a value of SOCKET_ERROR
is returned, and a specific error code can be retrieved by calling
WSAGetLastError.
</quote>

When I decided to use blocking functions, I expected to have a Recv()
that didn't proceed untill ALL data was sent, but now it seems that I
have to use it many times, until I get the data...

Yes!

Now I am confused, what should I do ?
...
Any idea ?

Replace the calls to send() and recv() with calls to your own versions - say
mySend() and myRecv(). In myRecv() you check the length you received against
what you expected. If you get less, you adjust the number of bytes by the
amount received, advance the pointer to the buffer to just past the last
byte received and repeat until you get the whole message or an error occurs.

The operation of mySend() is left as an exercise to the interested reader.

Regards,
Will


.

Relevant Pages

  • Re: wierd send/recv problem
    ... stream of bytes - it knows no "message" boundaries. ... If you call sendwith 1024 bytes, the recv() on ... The architecture of my receiver is as follows ... So basically, first message reaches properly, second message doesnt go ...
    (microsoft.public.win32.programmer.networks)
  • Re: sending images over a socket
    ... > A recv() call only returns the data received up to that point. ... > in the sockets implementation, ... > the receiver must fetch this length first, ... > - The sender and receiver always know exactly how much data is transferred ...
    (comp.unix.programmer)
  • Re: sending images over a socket
    ... A recv() call only returns the data received up to that point. ... It may close it's sending socket when it has sent all the data; the receiver ... The sender and receiver always know exactly how much data is transferred as ... that fixed amount is; both sender and receiver must agree on what this amount ...
    (comp.unix.programmer)
  • Re: select.select and socket.setblocking
    ... with TCP protocol recv only returned less than the required bytes if the remote end disconnects. ... kind of network congestion that could cause recv to return less than the expected amount of bytes ... ... IIRC TCP guarantees that the packet is fully received by hand-shaking at transport level between sender and receiver. ...
    (comp.lang.python)
  • send/recv socket calls
    ... I was just trying to understand the send/recv socket calls. ... just does a recv for 10, what exactly is going to happen? ... block until the receiver receives all the bytes. ... read from the byte stream? ...
    (comp.unix.solaris)