client-server data transfers appended with funny characters

Discussion in 'C++' started by Matt, Jul 11, 2004.

  1. Matt

    Matt Guest

    I wrote the tcp socket client-server program that the server will
    echo the message received from the client.

    In client program:
    char sendBuf[100];
    while(1)
    {
    cout << "Enter message:";
    cin.getline(sendBuf,100);
    rVal = send(theSocket, sendBuf, strlen(sendBuf), 0);
    }

    In server program:
    char recvBuf[100];
    while (1)
    {
    rVal = recv(s, recvBuf, strlen(recvBuf), 0);
    cout << "Echo: " << recvBuf << endl; //appends garable charcters
    cout << recvBuf << endl;
    //try to clear the buffer first for every echo, but it turned out
    //couldn't get any data from client
    //strcpy(recvBuf,""); <---------------------
    }

    The problem is recvBuf variable is appended with funny characters for
    every
    echo. And I think I need to clean up the buffer for every echo;
    otherwise
    it will append with previous data. The output of recvBuf is like this:

    Echo: hello world ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦`?
    Echo: erere world¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦?
    Echo: weee world¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦?
    ^C

    If I initialize recvBuf as follows, then server program is not able to
    get data from client

    strcpy(recvBuf,"");


    any workarounds to the problem? please advise!! thanks!
    Matt, Jul 11, 2004
    #1
    1. Advertising

  2. On 10 Jul 2004 19:32:57 -0700, Matt <> wrote:

    > I wrote the tcp socket client-server program that the server will
    > echo the message received from the client.
    >
    > In client program:
    > char sendBuf[100];
    > while(1)
    > {
    > cout << "Enter message:";
    > cin.getline(sendBuf,100);
    > rVal = send(theSocket, sendBuf, strlen(sendBuf), 0);
    > }
    >
    > In server program:
    > char recvBuf[100];
    > while (1)
    > {
    > rVal = recv(s, recvBuf, strlen(recvBuf), 0);
    > cout << "Echo: " << recvBuf << endl; //appends garable charcters
    > cout << recvBuf << endl;
    > //try to clear the buffer first for every echo, but it turned out
    > //couldn't get any data from client
    > //strcpy(recvBuf,""); <---------------------
    > }
    >
    > The problem is recvBuf variable is appended with funny characters for
    > every
    > echo. And I think I need to clean up the buffer for every echo;
    > otherwise
    > it will append with previous data. The output of recvBuf is like this:
    >
    > Echo: hello world
    > ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    > ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦`?
    > Echo: erere
    > world¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    > ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦?
    > Echo: weee
    > world¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    > ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦?
    > ^C
    >
    > If I initialize recvBuf as follows, then server program is not able to
    > get data from client
    >
    > strcpy(recvBuf,"");
    >
    >
    > any workarounds to the problem? please advise!! thanks!


    I don't know anything about recv and send but I can easily see that you
    have undefined behaviour in your code.


    char recvBuf[100];
    while (1)
    {
    rVal = recv(s, recvBuf, strlen(recvBuf), 0);

    recvBuf is uninitialised data, yet the first thing you do is call
    strlen(recvBuf). You are lucky that doesn't crash your program. Certainly
    you will get a completely arbitary value from strlen(recvBuf).

    Now as I said I don't know anything about recv, but I would *guess* that
    the third parameter is meant to specify the size of the buffer passed in
    the second parameter so that recv knows how much memory its got to play
    with. Therefore I would try sizeof not strlen

    char recvBuf[100];
    while (1)
    {
    rVal = recv(s, recvBuf, sizeof recvBuf, 0);

    If that doesn't work then RTFM.

    john
    John Harrison, Jul 11, 2004
    #2
    1. Advertising

  3. On 10 Jul 2004 19:32:57 -0700, Matt <> wrote:

    > I wrote the tcp socket client-server program that the server will
    > echo the message received from the client.
    >
    > In client program:
    > char sendBuf[100];
    > while(1)
    > {
    > cout << "Enter message:";
    > cin.getline(sendBuf,100);
    > rVal = send(theSocket, sendBuf, strlen(sendBuf), 0);
    > }
    >


    More guesses about your code but I would imagine that you really want this

    rVal = send(theSocket, sendBuf, strlen(sendBuf) + 1, 0);

    by saying 'strlen(sendBuf) + 1' you are ensuring that the null byte at the
    end of your string gets sent. Just a guess, again.

    john
    John Harrison, Jul 11, 2004
    #3
  4. Matt

    jota Guest

    > rVal = send(theSocket, sendBuf, strlen(sendBuf), 0);
    > rVal = recv(s, recvBuf, strlen(recvBuf), 0);


    There is two solutions
    1. Client sends nullterminator. (strlen(sendBuf)+1)
    2. Server appends nullterminator. (recvBuf[noreceived]=0)
    //jota
    jota, Jul 11, 2004
    #4
  5. Matt

    Matt Guest

    thanks a lot!!

    I just tried different ways, if I do the following

    > > rVal = recv(s, recvBuf, 100, 0);


    rather than

    > > rVal = recv(s, recvBuf, strlen(recvBuf), 0);

    or
    > > rVal = recv(s, recvBuf, strlen(recvBuf)+1, 0);


    Then, it is working fine. But I still don't quite understand the
    rationale, because I thought strlen(recvBuf)+1 already represents the
    packet length. 100 is the maximum length of the packet that I defined
    for the recvBuf variable.

    please advise. thanks!!
    Matt, Jul 12, 2004
    #5
  6. On 11 Jul 2004 22:50:14 -0700, Matt <> wrote:

    > thanks a lot!!
    >
    > I just tried different ways, if I do the following
    >
    >> > rVal = recv(s, recvBuf, 100, 0);

    > rather than
    >
    >> > rVal = recv(s, recvBuf, strlen(recvBuf), 0);

    > or
    >> > rVal = recv(s, recvBuf, strlen(recvBuf)+1, 0);

    >
    > Then, it is working fine. But I still don't quite understand the
    > rationale, because I thought strlen(recvBuf)+1 already represents the
    > packet length. 100 is the maximum length of the packet that I defined
    > for the recvBuf variable.
    >


    No, how can strlen(recvBuf)+1 represent the packet length when
    strlen(recvBuf)+1 is called *before* you received the packet? At best
    strlen(recvBuf)+1 will be the length of the *last* packet you received not
    the packet you are *about* to receive.

    In any case recv does not need to know the packet length, you've got that
    wrong. It does need to know the size of the buffer you have given it
    (which is nothing to do with the packet length). In your case the size of
    the buffer is 100 bytes, so that is what you should put for the third
    argument.

    *After* you have called recv, then you have a packet, and then (depending
    on what you sent) is might be sensible to call strlen(recvBuf)+1 to find
    out how big the packet is. Although I think rVal will tell you the same
    information.

    But think about it, you cannot find out how long a packet is until *after*
    you have received the packet, that seems obvious.

    john
    John Harrison, Jul 12, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Karl Seguin
    Replies:
    1
    Views:
    429
  2. Matt
    Replies:
    2
    Views:
    390
    Dave Thompson
    Jul 19, 2004
  3. alexey
    Replies:
    2
    Views:
    109
    alexey
    Apr 2, 2004
  4. Brian Barnes

    large data transfers

    Brian Barnes, Jun 3, 2004, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    117
    Brian Barnes
    Jun 3, 2004
  5. libsfan01
    Replies:
    5
    Views:
    229
    Jeff North
    Dec 20, 2006
Loading...

Share This Page