Sending and Receiving over socket - Unix

This is a discussion on Sending and Receiving over socket - Unix ; Hi Everyone, I have a question. If I have a client and a server machine and on my client machine I execute this code: send (socketfd, &rHeader, 2 * sizeof(int)), 0); and on my server machine I execute: recv (socketfd, ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Sending and Receiving over socket

  1. Sending and Receiving over socket

    Hi Everyone,
    I have a question. If I have a client and a server machine and on my
    client machine I execute this code:

    send (socketfd, &rHeader, 2 * sizeof(int)), 0);

    and on my server machine I execute:

    recv (socketfd, &buffer, 2 * sizeof*(int)), 0);

    can I be sure that the full buffer will be sent and received when
    these two are executed. If not is there a way to make sure that these
    two I done. I guess I am looking for a function like fflush() but for
    sockets.

    Thanks


  2. Re: Sending and Receiving over socket

    On Apr 14, 9:12 pm, "Jack" wrote:
    > Hi Everyone,
    > I have a question. If I have a client and a server machine and on my
    > client machine I execute this code:
    >
    > send (socketfd, &rHeader, 2 * sizeof(int)), 0);
    >
    > and on my server machine I execute:
    >
    > recv (socketfd, &buffer, 2 * sizeof*(int)), 0);
    >
    > can I be sure that the full buffer will be sent and received when
    > these two are executed.


    Yes and no.

    The send() will schedule transmission of the data you've provided. It
    is up to the sockets, tcp/ip and ethernet/ppp layers to determine
    whether the data will consist of one packet or multiple packets, and
    schedule the transmission of the packets.

    On the recv() side, recv() will only return the data that has been
    received and dequeued. This /may/ be less than the amount you sent.
    You will have to recv() until you have received all the data.

    > If not is there a way to make sure that these two I done.


    On the sending side, you can close the tcp connection (assuming a
    stream socket). This will force the scheduling (in due time) of the
    transmission of the remaining data. However, as you will have closed
    the connection, you won't be able to send any more data across that
    connection. And, assuming that you did not perform a half-close, you
    won't be able to receive any data at the sending side either.

    > I guess I am looking for a function like fflush() but for sockets.


    AFAIK, there aint no such thing

    HTH
    --
    Lew



    > Thanks




  3. Re: Sending and Receiving over socket

    On Apr 14, 6:12 pm, "Jack" wrote:
    > Hi Everyone,
    > I have a question. If I have a client and a server machine and on my
    > client machine I execute this code:
    >
    > send (socketfd, &rHeader, 2 * sizeof(int)), 0);
    >
    > and on my server machine I execute:
    >
    > recv (socketfd, &buffer, 2 * sizeof*(int)), 0);
    >
    > can I be sure that the full buffer will be sent and received when
    > these two are executed.


    You need to check the return values. If 'send' returns 1, then it will
    only attempt to send one bytes. If 'recv' returns 3, then it only
    received three bytes.

    > If not is there a way to make sure that these
    > two I done. I guess I am looking for a function like fflush() but for
    > sockets.


    A function like 'fflush' would be of no help. In the receive case, how
    would it know how many bytes to wait for? In the send case, any data
    is already queued to be sent when possible, and there is no way for
    the stack to know when the application on the other side has gotten
    the data.

    You seem to be missing the basics about TCP. You really need to read
    up on TCP in some more detail.

    DS


  4. Re: Sending and Receiving over socket

    Lew Pitcher wrote:
    >The send() will schedule transmission of the data you've provided. It
    >is up to the sockets, tcp/ip and ethernet/ppp layers to determine
    >whether the data will consist of one packet or multiple packets, and
    >schedule the transmission of the packets.


    Hey, Lew--sorry to bring up the old topic, but I want to make sure I
    understand this. It sounds like you're saying send() will completely
    handle large amounts of data to be sent.

    With AF_UNIX sockets, Linux blocks if you send too much without calling
    recieve, unless you call send() with MSG_DONTWAIT, in which case it
    returns immediately with the number of bytes actually sent.

    With AF_INET across a LAN (or localhost), I get short sends regardless
    of whether or not MSG_DONTWAIT is specified, e.g. out of 400000 bytes,
    14480 are sent, and 1448 (10x fewer) are recv'd. (This is a single
    send() and single recv() call, obviously.)

    This is in spite of what it says in the man page:

    When the message does not fit into the send buffer of the socket,
    send() normally blocks, unless the socket has been placed in
    non-blocking I/O mode. In non-blocking mode it would return EAGAIN in
    this case.

    Should I be seeing different behavior, or am I misunderstanding you?

    Thanks,
    -Beej


+ Reply to Thread