Printable View
Hi, I'm trying to create a game query program, which sends a query to the server through UDP, and the server sends a response back, with some info about the server.
The response of the server is stored in char * data; But now my question, how do I convert to bytes (actually 2 char's) to a short value?
If you two byte data has the format of a short int do this:[edited: casting]
If it hasn't why converting?Code:short* sdata = static_cast<short*>(data);
Well, this will be the response of a Doom 3/Enemy territory: Quake Wars server:
http://www.int64.org/docs/gamestat-protocols/doom3.html
The player's ping and rate are int16, and because I receive the data as a char *, I need to convert it.
I guess, I can use the cast?
Am I right? This string (data) has both ping and rate (and more data?) after each other.
Yep, that's true. C# has a nice BitConverter class, which allows you to convert some specific bytes at a specific offset to an other data type.
You must not see this as a string, but as a byte sequence.
So you need the offset of rate and ping in the string. Suppose ping is byte 3 to 5 and rate is 5to 7. (zero based indexing)
Now our new pointers point to ping and rate in data string.Code:short* ping_ptr = static_cast<short*> (data + 3);
short* rate_ptr = static_cast<short*> (data + 5);
Ok, thanks :) I think I understand it, and when I de-reference them, I've got the short value isn't it?
Yes, you will.
But I think there is better way. You should make a struct with the feelds :
ping
rate
etc
And then fill them with data.
i could be off here, but can't you do something like...
short s1 = (short) ((chrdata >> N) & 0xFF...F)
an example scenerio:
i have an int with rgb values in it, to get it out you do
for example...
iRGB = 0xFFA19300 //0xRRGGBB00
// r = 255 -> 0xFF ... and so on
so i'd capture the values by doing...
int r = (iRGB >> 16) & oxFF
int g = (iRGB >> 8) & oxFF
int b = (iRGB) & oxFF
same concept.... right?
No you can't do it with data because it is a pointer to a string. Bitwise operators work on variables not strings. In strings we don't need them because each byte is addressable directly.
In addition to the cast, you might need to convert the bytes from network order to host order:Quote:
Originally Posted by MrLucky
Code:short sdata = ntohs(*static_cast<short *>(data));
It is pointer to character array (not each char array is a string)Quote:
Originally Posted by siavoshkc
and of course each member of the array is a char - so we CAN apply bitwise operations to the members of the array.
Of course you can. But it doesn't give you anything useful in this case. I said we can not do it on strings. But you can do it on each character.Quote:
It is pointer to character array (not each char array is a string)
and of course each member of the array is a char - so we CAN apply bitwise operations to the members of the array.
It depends on what is stored there... If some short value is stored as 2 bytes char array for sending throgh the network - of course the bitwise operation will give you something useful - the original value.Quote:
ut it doesn't give you anything useful in this case.
Can you give me an example? I think this threrad is where you should explain.
(code may not be correct)
A char is as an int, a series of binary values. and a series of chars is a string, correct?
int BLA = (int)( ( (*STRING)[x] >> n ) & 0xFF...F );
(*STRING)[x] <-- points to a char
((*STRING)[x])>>n) <-- shift the values of the char
(int)( ( (*STRING)[x] >> n ) & 0xFF...F ) <-- ... mask to save the intended data in an int instead... vola you have your values from the stream of 2 byte chars.
i'm assuming the data is formatted in to a stream of bits really, which is captures as 2byte chars, but can contain other data... this is a way to get that data.
in one of my projects values are received as a stream of bits representing INT values, each int has two shorts formatted in it, for two channels of data... i capture both channels in a similar fashion as above.
unless i'm talking about an idea that still doesn't apply, i'm only suggesting from what it sounds like to me that this can apply.
let's say the standard is first 16 bits is a short, the rest is what ever, then when you capture this information you can apply bit manipulation to get the formatted data as intended.
if STRING is a char pointer.
(*STRING)[x] <-- Doesn't point to anything. derefferenced twice!
from one of my projects:
static int j = 0;
for (j=0; j<SMPSIZE; ++j)
{
chL = (((int *)alBuffer)[j] >> 0) & 0xFFFF; // -32768 -> 32767
chR = (((int *)alBuffer)[j] >> 16) & 0xFFFF; // -32768 -> 32767
vChL.push_back( chL / float(SHRT_MAX) );
vChR.push_back( chR / float(SHRT_MAX) );
}
alBuffer is a buffer holding streamed data as ALint type. See what I'm talking about?
If he needs data out of a stream, formatted a specific way, he do the same thing, regardless if it's chars or what ever.
I think it wont work for string. I'm waiting for vart to explain. Maybe he thinks data are overlapped on byte boudaries. Then you may use bitwise operation. Otherwise I don't see any need.
OK. It works. Now our problem:Code:int BLA = (int)( ( (STRING)[x] >> n ) & 0xFF...F );
(STRING)[x] <-- points to a char
((STRING)[x])>>n) <-- shift the values of the char
We have string like this:Suppose "data" is pointing to first byte with index '0'. It is data[0] == *data. Now if we do a bitwise operation on byte 3 (data[2]), compiler see only one byte to manipulate not its neigbors. We don't need it in this case as I can see.Code:01101101|01011101|11011010|11000001
Suppose I have
short unsigned value = 0xABCD;
And I need to send it to another process using socket...
I will use
send(fd,&value, sizeof value);
Right? Wrong... This will make my code unportable and cause problems if the sender and reciever are using different endian architecture...
What will I do, I will construct a byte array like this:
What will I do after receiving char array to restore the sent value?Code:unsigned char data[2];
data[0] = value & 0xFF; /* low byte */
data[1] = (value >> 8) & 0xFF; /* high byte */
send(fd, data, sizeof data);
In this case I'm not interested to know if the byte order on sender and receiver for representing short is the same or not;Code:value = data[1];
value <<= 8;
value |= data[0];
Tricky method. It works because in the platform that executes:System knows that low byte is the bigger or smaller byte address, so data[0] will have the low byte. And reverse operation is done in destination. Data in the network will be big endian. Right?Code:data[0] = value & 0xFF; /* low byte */
In this case we don't know if its true or not.
This is why you do your research and learn the standards in formatting data for various protocols. Which is out of the scope for solving the technical issue, which is what we're providing. How the information is received on the other end is irrelevant since you capture information designed to work in what ever protocol you are communicating over. You have to trust at the other end the software is written to capture and present the information correctly. You have to assume that the information being sent to you as well was formatted correctly as the standard requires for what ever protocol your using, so you can assume how the information will get to you.Quote:
Data in the network will be big endian. Right?
In this case we don't know if its true or not
If you're writing both the server and client side, then you have to make sure you understand how information is formatted on both local systems and write your code accordingly.
There's no guess work involved. This is why standards for communicating over networks exist, and why people abide by them.
So you don't need to worry if the information will get to you as it should, as long as everyone agrees to the standards you're guaranteed the data to be intact as documented. So you do know the binary format, by understanding what your capturing information from, which the programmer must know to capture the data he wants to represent it.
The solution was after this point, how to get the meaningful data out of the stream, this is via bitwise operators shifting stream information and masking to extract the intended data, as said above.
I hope I didn't misunderstand you, but it seems that was your concern.