C++ Websocket recv 2 bytes - c++

Helo. I'm working on a C++ Websocket library. All was ok until one strange problem appeared.
int n = 0, n_add = 0;
char *buf = (char*)malloc(BUFLEN);
char new_buffer[4096];
while ((n = recv(client_id, buf, BUFLEN, 0)) > 0) {
strcat(new_buffer, buf);
int new_buffer_length = strlen(new_buffer);
int buf_length = strlen(buf);
n_add+= n;
// debug
cout << "buf: '" << buf << "'" << endl;
cout << "new_buffer_length: '" << new_buffer_length << "'" << endl;
cout << "buf_length: '" << buf_length << "'" << endl;
cout << "n: '" << n << "'" << endl;
cout << "n_add: '" << n_add << "'" << endl;
memset(buf, '\0', BUFLEN);
if (n_add == new_buffer_length && n < BUFLEN) {
cout << "new_buffer: '" << new_buffer << "'" << endl;
// if client is already connected
if (ws_clients[client_id][2] == WS_READY_STATE_OPEN) {
this->ws_client_message(client_id, new_buffer, new_buffer_length);
}
// if client needs a handshake
if (ws_clients[client_id][2] == WS_READY_STATE_CONNECTING) {
this->ws_client_handshake(client_id, new_buffer);
}
memset(&new_buffer, '\0', 4096);
n_add = 0;
FD_ZERO(&this->tmp_fds);
}
}
The handshake is done perfectly aswell as any payload that is less than 126. When that happends i get this:
buf: 'þ'
new_buffer_length: '2'
buf_length: '2'
n: '128'
n_add: '128'
buf: '½HÆA¯J'
new_buffer_length: '8'
buf_length: '6'
n: '6'
n_add: '134'
The n says i recived 128 bytes but it's actually only 2, the second time gives me 6 bytes, and those are ok. If i change my BUFLEN which is limited to 128 and put to 2, i'm getting everything ok, except for the last loop, it never gets to 134, the actual payload length.
Ok so if everybody has any idea, i'm using http://www.websocket.org/echo.html for testing, i tried everything. please give me some hints

The data framing section of RFC6455 shows that websocket messages are not plain text and are not null-terminated strings. You can't use C string handling functions like strlen or strcat on messages you read.
If you want to keep using C strings, use n to determine the number of bytes you have read and strncpy to add that to a buffer. Since you're writing a C++ server though, you'll probably find things easier if you switch to using std::string instead.
The difference in handling messages around 128 chars probably comes from the fact that the number of bytes used to indicate the length of the message increases for payloads longer than 125 bytes. For messages between 126 and 255 bytes long, there will be a zero byte in the extended payload length. Your code will (incorrectly) interpret this as the terminator of a C string.

A char* is not necessarily a C string, It has to be properly terminated.
while ((n = recv(client_id, buf, BUFLEN, 0)) > 0) {
strcat(new_buffer, buf);
....
This spells problem, whatever received in buf, may not be '\0' terminated.
and when you call strcat, it wouldn't work.
checkout the manual of strcat and strncat function, make sure you use these function correctly.

Related

Server not receiving trailing longs in c++ socket

I am transferring a struct over socket using c++. I read some earlier questions on sending structs and one approach suggested was to transfer using a char* after cast. Since both server and client are on same machine so no issues of endianness here.
Couple of questions here. I get size of struct as 48. As per my calculation shouldn't it be 43? 8x4 + 10 +1
Secondly on server side when i print the received buffer I only get the text elements. The long integers are not received.
struct testStruct{
char type;
char field1[10];
char field2[8];
char field3[8];
long num1, num2;
};
testStruct ls;
ls.type = 'U';
strcpy(ls.field1, "NAVEENSHAR");
strcpy(ls.field2, "abcd1234");
strcpy(ls.field3, "al345678");
ls.num1 = 40;
ls.num2 = 200;
char* bytes = static_cast<char*>(static_cast<void*>(&ls));
bytes_sent = send(socketfd, bytes, sizeof(ls), 0);
cout << "bytes sent: " << bytes_sent<< "\n";
//On server sidechar
incomming_data_buffer[1000];
bytes_recieved = recv(new_sd, incomming_data_buffer,1000, 0);
cout << "|" << incomming_data_buffer << "|\n";
It shows 48 bytes received and no trailing integers which i added.
Any idea on why this could be happening. I have read about sending structs using boost serialization but at the same time that overhead is huge for simple structs.
You are almost certainly receiving all the data. The problem is with this line:
cout << "|" << incomming_data_buffer << "|\n";
which prints incomming_data_buffer as a C style string, so stops at the first zero-byte. Since your long values are encoded in binary for, there will be zeros at least there (there may also be zeros in the padding between fields).
You could try doing something like:
cout << "|";
for (int i = 0; i < bytes_received; i++)
{
cout << hex << (((int)incomming_data_buffer[i]) & 0xff) << " ";
}
cout << "|\n";
to show all bytes of the package you received.

Parsing protocol buffers in c++

I wanted to write some protocol buffers to the socket and read it back from the client side. Things didn't work so I wrote some decoding part in the server itself right after I encoded it. Can you please take a look at the code below and tell me what I am doing wrong ?
(I had to use arraystream and coded stream so that I can write a delimiter)
int bytes_written = tData.ByteSize() + sizeof(google::protobuf::uint32);
google::protobuf::uint8 buffer[bytes_written];
memset(buffer, '\0', bytes_written);
google::protobuf::io::ArrayOutputStream aos(buffer,bytes_written);
google::protobuf::io::CodedOutputStream *coded_output = new google::protobuf::io::CodedOutputStream(&aos);
google::protobuf::uint32 size_ = tData.ByteSize();
coded_output->WriteVarint32(size_);
tData.SerializeToCodedStream(coded_output);
int sent_bytes = 0;
std::cout << buffer << std::endl;
if ( (sent_bytes = send(liveConnections.at(i), buffer, bytes_written, MSG_NOSIGNAL)) == -1 )
liveConnections.erase(liveConnections.begin() + i);
else
std::cout << "sent " << sent_bytes << " bytes to " << i << std::endl;
delete coded_output;
////////////////
google::protobuf::uint8 __buffer[sizeof(google::protobuf::uint32)];
memset(__buffer, '\0', sizeof(google::protobuf::uint32));
memcpy (__buffer, buffer, sizeof(google::protobuf::uint32));
google::protobuf::uint32 __size = 0;
google::protobuf::io::ArrayInputStream ais(__buffer,sizeof(google::protobuf::uint32));
google::protobuf::io::CodedInputStream coded_input(&ais);
coded_input. ReadVarint32(&__size);
std::cout <<" size of payload is "<<__size << std::endl;
google::protobuf::uint8 databuffer[__size];
memset(databuffer, '\0', __size);
memcpy (databuffer, buffer+sizeof(google::protobuf::uint32), __size);
std::cout << "databuffs " << "size " << __size << " "<< databuffer << std::endl;
google::protobuf::io::ArrayInputStream array_input(databuffer,__size);
google::protobuf::io::CodedInputStream _coded_input(&array_input);
data_model::terminal_data* tData = new data_model::terminal_data();
if (!tData->ParseFromCodedStream(&_coded_input))
{
std::cout << "data could not be parsed" << std::endl;
}
else
{
std::cout <<" SYMBOL --" << tData->symbol_name() << std::endl;
}
delete tData;
Out put of the program:
size of payload is 55
databuffs size 55 C109"056* BANKNIFTY0���20140915#�J 145406340
data could not be parsed
C109"056* BANKNIFTY0���20140915#�J 145406340
WriteVarint32 doesn't necessarily write 4 bytes, and ReadVarint32 doesn't read 4 bytes. "Var" stands for "variable", as in "variable length encoding".
When encoding, you write the size (which can take as little as one byte), then immediately the proto. When decoding, you read the size, then advance by four bytes, then read the proto. So, you are parsing starting from the wrong offset.
Use CurrentPosition() after ReadVarint32 to figure out how many bytes the size indicator consumed. Advance by that number of bytes.

Issue with GPB SerializeTo functions

I have the below code.
main()
{
test::RouteMessage *Rtmesg = new test::RouteMessage;
test::RouteV4Prefix *prefix = new test::RouteV4Prefix;
test::RouteMessage testRtmesg;
prefix->set_family(test::RouteV4Prefix::RT_AFI_V4);
prefix->set_prefix_len(24);
prefix->set_prefix(1000);
Rtmesg->set_routetype(test::RouteMessage::RT_TYPE_BGP);
Rtmesg->set_allocated_v4prefix(prefix);
Rtmesg->set_flags(test::RouteMessage::RT_FLGS_NONE);
Rtmesg->set_routeevnt(test::RouteMessage::BGP_EVNT_V4_RT_ADD);
Rtmesg->set_nexthop(100);
Rtmesg->set_ifindex(200); Rtmesg->set_metric(99);
Rtmesg->set_pref(1);
int size = Rtmesg->ByteSize();
char const *rt_msg = (char *)malloc(size);
google::protobuf::io::ArrayOutputStream oarr(rt_msg, size);
google::protobuf::io::CodedOutputStream output (&oarr)
Rtmesg->SerializeToCodedStream(&output);
// Below code is just to see if everything is fine.
google::protobuf::io::ArrayInputtStream iarr(rt_msg, size);
google::protobuf::io::CodedInputStream Input (&iarr)
testRtmesg.ParseFromCodedStream(&Input);
Vpe::RouteV4Prefix test_v4Prefix = testRtmesg.v4prefix();
cout << std::endl;
std::cout << "Family " << test_v4Prefix.family() << std::endl;
std::cout << "Prefix " << test_v4Prefix.prefix()<< std::endl;
std::cout << "PrefixLen " << test_v4Prefix.prefix_len() << std::endl;
// All the above outputs are fine.
cout << std::endl;
cout << rt_msg; <<------------ This prints absolutely junk.
cout << std::endl;
amqp_bytes_t str2;
str2 = amqp_cstring_bytes(rt_msg); <<----- This just crashes.
printf("\n str2=%s %d", str2.bytes, str2.len);
}
Any operation on the above rt_msg just crashes. I want to use the above buffer to send to socket and another rabbitmq publish APIs.
Anybody out there who had similar issue...or worked out similar code ?
Protocol Buffers is a binary serialization format, not text. This means:
Yes, if you write the binary data to cout, it will look like junk (or crash).
The data is not NUL-terminated like C strings. Therefore, you cannot pass it into a function like amqp_cstring_bytes which expects a NUL-terminated char* -- it may cut the data short at the first 0 byte, or it may search for a 0 byte past the end of the buffer and crash. In general, any function that takes a char* but does not also take a length won't work.
I'm not familiar with amqp, but it looks like the function you are trying to call, amqp_cstring_bytes, just builds a amqp_bytes_t, which is defined as follows:
typedef struct amqp_bytes_t_ {
size_t len;
void *bytes;
} amqp_bytes_t;
So, all you have to do is something like:
amqp_bytes_t str2;
str2.bytes = rt_msg;
str2.len = size;

Fencepost conditions and portability for using of snprintf()?

Given the following code:
const int size = 20;
char buffer[size];
// From the Linux man page for snprintf():
//
// The 'res' is the number of bytes that would be written to buffer had size been
// sufficiently large excluding the terminating null byte. Output bytes beyond
// the size-1st are discarded instead of being written to the buffer, and a null
// byte is written at the end of the bytes actually written into the buffer.
int res = snprintf(buffer, size, "some format with %d and %s", 23, "some string");
if (res >= size) {
cerr << "The buffer was not large enough, we needed " << res
<< " but only had " << size << "." << endl;
} else {
cout << "The buffer is big enough, we only needed " << res
<< " but had " << size << "." << endl;
}
Is this portable and if so, did I get all the fencepost conditions correct?
1 Passing size to snprintf()
2 Checking res being greater than or equal to size
snprintf isn't strictly speaking portable, as it's not part of the C/C++ standards. Windows has it as _snprintf - but otherwise identical.
The fencepost conditions are all fine. Your printf's aren't entirely fine, in the equals case it's going to print
The buffer was not large enough, we needed 215 but only had 215.

std::cout << stringstream.str()->c_str() prints nothing

in a function, that gets unsigned char && unsigned char length,
void pcap_callback(u_char *args, const struct pcap_pkthdr* pkthdr, const u_char* packet)
{
std::vector<unsigned char> vec(packet, packet+pkthdr->len); // optimized from foo.
std::stringstream scp;
for (int i=0;i<pkthdr->len;i++) {
scp<<vec[i];
}
std::string mystr = std::string(scp.rdbuf()->str());
std::cout << "WAS: " << packet << std::endl;
std::cout << "GOOD: " << scp.str() << std::endl;
std::cout << "BAD: " << scp.str().c_str() << std::endl;
std::cout << "TEST: " << mystr.size() << std::endl;
assert(mystr.size() == pkthdr->len);
}
Results:
WAS: prints nothing (guess there is a pointer to const.. case)
GOOD: prints data
BAD: prints nothing
TEST, assert: prints that mystr.size() is equal to passed unsigned char size.
I tried:
string.assign(scp.rdbuf());
memcpy(char, scp.str(), 10);
different methods of creating/allocating temporary chars, strings
No help.. it is wanted to get a std::cout'able std::string that contains data, (which was picked from foo, which was unsigned char, which was packet data).
Guessing either the original foo may not be null-terminated, or the problem is something like this - simple, but can't get in.. what are the things to look for here?
(this code is another attempt to use libpcap, just to print packets in C++ way, without using known C++ magic wrappers like libpcapp).
For a quick test, throw in a check for scp.str().size() == strlen(scp.str().c_str()) to see if there are embedded '\0' characters in the string, which is what I suspect is happening.
I think you're going about this the wrong way. It looks like you're dealing with binary data here, in which case you can't expect to meaningfully output it to the screen as text. What you really need is a hex dump.
const unsigned char* ucopy = packet;
std::ios_base::fmtflags old_flags = std::cout.flags();
std::cout.setf(std::ios::hex, std::ios::basefield);
for (const unsigned char* p = ucopy, *e = p + pkthdr->len; p != e; ++p) {
std::cout << std::setw(2) << std::setfill('0') << static_cast<unsigned>(*p) << " ";
}
std::cout.flags(old_flags);
This will output the data byte-by-byte, and let you examine the individual hex values of the binary data. A null byte will simply be output as 00.
Check std::cout.good() after the failed output attempt. My guess is that there's some failure on output (i.e. trying to write a nonprintable character to the console), which is setting failbit on cout.
Also check to ensure the string does not start with a NULL, which would cause empty output to be the expected behavior :)
(Side note, please use reinterpret_cast for unsigned char *ucopy = (unsigned char*)packet; if you're in C++ ;) )