By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,659 Members | 1,957 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,659 IT Pros & Developers. It's quick & easy.

client-server data transfers appended with funny characters

P: n/a
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!
Nov 14 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
jr********@hotmail.com (Matt) writes:
{
cout << "Enter message:";
cin.getline(sendBuf,100);
rVal = send(theSocket, sendBuf, strlen(sendBuf), 0);
}


This is not C.
Nov 14 '05 #2

P: n/a
On 10 Jul 2004 19:32:31 -0700, jr********@hotmail.com (Matt) wrote:
I wrote the tcp socket client-server program that the server will
echo the message received from the client.
"Echo" normally means to send back to the client. What you would be
doing except for your bugs is displaying or outputting the message.
Sockets as such are not part of standard C (or for that matter C++)
and thus offtopic, but your actual errors are in the C part of what
you did.
In client program:
char sendBuf[100];
while(1)
{
cout << "Enter message:";
cin.getline(sendBuf,100);
This is C++ and off topic, except that it does (normally) leave a
valid, that is null-byte-terminated, string in sendBuf, which the
following and also offtopic send() therefore sends correctly.
rVal = send(theSocket, sendBuf, strlen(sendBuf), 0);
}

In server program:
char recvBuf[100];
This is a local or "automatic" variable with no initializer, and so is
not initialized; it may contain arbitrary garbage.
while (1)
{
rVal = recv(s, recvBuf, strlen(recvBuf), 0);
The first time through, strlen() uses the unitialized contents of
recvBuf to try to determine its length; technically this is Undefined
Behavior and anything is permitted happen up to and including turning
your fingers green, but in practice it will probably just produce some
wrong value, which is passed to recv(). On each subsequent loop it
tries to use the previous contents to determine the length, but since
recv does not add a null terminator and neither does your code it will
still be wrong, though not (additional) Undefined Behavior.

Probably this value will be too small, in which case you may fail to
recv() all the data as the sender sent -- and note that for TCP this
may happen anyway, TCP is a byte-stream protocol and does NOT
guarantee to preserve "message" boundaries, although for short
isolated messages usually it will "by accident" and you won't discover
your code is badly wrong until it's embedded in a large, complicated,
and deployed program and much more difficult and costly to repair.
Possibly the strlen() value is too big, in which case *if* the sender
sends too much data, which your *sample* client won't but an attacker
will, it can crash or "r00t" your system. Either way it's a bad idea.

What you want to use is sizeof(recvBuf) or perhaps that -1, see below
-- but only if the array declaration is visible as here, not if it's
within a function to which you pass it as a parameter because then the
size is NOT known or automatically passed, you must either pass it or
have some other means of determining it.

recv() is offtopic except for the fact that it, barring error, returns
the number of characters stored but does NOT add a null terminator.
cout << "Echo: " << recvBuf << endl; //appends garable charcters
cout << recvBuf << endl;
Again the C++ part is offtopic except for the fact that it expects a
null-terminated string which you haven't given it. You could add the
null-terminator, which is more convenient for C, in which case you
should have received only sizeof(recvBuf)-1 to ensure room, or
alternatively allocate the buffer for say [MAXREAD+1] and recv for
MAXREAD. Or use basic_ostream::write or construct a std::string for
the valid length and output that; see comp.lang.c++ for those.
//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,"");
Right, because now strlen() reliably returns 0 and you try to recv at
most 0 bytes; see above.

any workarounds to the problem? please advise!! thanks!


- David.Thompson1 at worldnet.att.net
Nov 14 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.