Re: sending images over a socket

From: Joaquin López (lsanchez_at_lsi.uji.es)
Date: 12/09/03


Date: Tue, 09 Dec 2003 18:17:35 +0100

Lew Pitcher wrote:

> 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.
>
>

Thank you to all of us for helping me. The problem was exactly this, I
expected recv() will get all the data in only one call. It was my fault.



Relevant Pages

  • 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)
  • socket, select, timeout
    ... This is UDP sockets, with a sender and a receiver. ...
    (comp.os.linux.development.apps)
  • 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: Socket communication
    ... sockets. ... There are times when I need the sending app to wait on a the ... The sender then always knows what the receiver has gotten. ...
    (microsoft.public.vb.general.discussion)
  • Re: Neutral Format as a Coupling reduction idea that doesnt work.
    ... There are potentially unlimited and unexpected side effects for both sender and receiver. ... That definition defines the semantics of the just the data packet. ... That represents a solution level coupling but at least it is very narrowly focused on the message definition rather than what each side does with the information. ...
    (comp.object)