Re: sending images over a socket

From: Lew Pitcher (Lew.Pitcher_at_td.com)
Date: 12/08/03 

Date: Mon, 08 Dec 2003 16:51:56 GMT

On Mon, 8 Dec 2003 17:14:30 +0100, "Joaquin López" <lsanchez@lsi.uji.es> wrote:

>Hello, I'm writing a program for sending images over a socket.
>
>The size of the image is 640x480 pixels in pgm format.
>
>The problem is that when the client sends the image to the server (307200
>bytes) the server only receives 65533.
>
>The thing is, is there any limits on the information sent from one point
>(send) to another (recv)?.
>
>In such case, how is the way I have to send one image of 640x480 pixels?
>Perhaps in two times?

It is likely that you don't understand TCP communications and/or stream sockets.

A recv() call only returns the data received up to that point. There is no
synchronization between the data sent and the data received. That is to say that
although you may /send/ massive amounts of data in one call, the corresponding
recv() call does not have to (and usually won't) receive the data in one recv()
call. This is the nature of TCP/IP, and is not a flaw in the sockets
implementation, or anything else.

It appears that your /first/ recv() gets 64k of the data sent. You need to
continue issueing recv() calls (and appending the results together) until you
receive all the data you sent. How you determine that you have received /all/
the data depends on your sending program:
- It may close it's sending socket when it has sent all the data; the receiver
  will detect this as an end-of-file on the receiving socket, or
- It may send the length of the data as a data item prior to the data itself;
  the receiver must fetch this length first, then recv() until the length has
  been exhausted, or
- It may send a sentinal in the data stream to mark the end of the data; the
  receiver must be sensitive to this sentinal and trim it's recv()d data
  according to the placement of the sentinal, or
- The sender and receiver always know exactly how much data is transferred as
  the sender always sends a fixed amount of data, and the receiver knows what
  that fixed amount is; both sender and receiver must agree on what this amount
  is prior to the transmission of the data.

In all cases, both sender application and receiver application must agree upon
the strategy to be used to detect end of data, and both applications must be
coded to enact that strategy. 

-- 
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employers')

Relevant Pages

  • 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: Question: Designing a protocol over TCP
    ... Your receivecall will be completed as soon as an incoming TCP segment has ... Once your recv() call has been completed, ... sender and receiver side makes it possible for the receiver side to always ... complete recvcalls with exactly the number of bytes the sender has sent. ...
    (microsoft.public.win32.programmer.networks)
  • 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: Socket differences between localhost and LAN (or Internet)
    ... Recv() is not reliable, ok, is the Sendreliable too? ... I see that the total amount of received bytes is not what I expected, ... The other bytes of the transmission are in transit. ... along the path from sender to receiver. ...
    (microsoft.public.vc.ide_general)
  • 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)