Remote Frame Buffer protocol Programming

[m0mathur]

I do need clarification, I do want to understand something about RFB (VNC) protocols. I am writing a project to implement VNC and its protocols hence a rough google search made me to understand i have to get the screenshot and save as .bmp (I have done that and that works perfectly fine) and later on i can then get the width , height and the pixels programmatically and send via Winsock / TCP (Screen resolution to be very precise)

I know how to send strings via Winsock (Not much of an issue, as there are Tons and tons of examples on here) Now i want to send something like the width, height and pixels (screen Dimensions and pixels) so that i can do screen sharing and show on my MFC Application PictureBox

i am new to something like this, hence i wanted to know if I would do something like sprintf() to have the three values together? or how do i send the three values together so that the client (Viewer) can pick up and display from there.

[coder777]

if I would do something like sprintf() to have the three values together?

Yes, it is a rather good idea to turn the values into string and send that string. When you receive the string you need however make sure that it is complete.

You can do this with streams as well. For instance using std::stringstream:

http://www.cplusplus.com/reference/sstream/stringstream/?kw=stringstream

[m0mathur]

Means one of the ways i would also like to send this BITMAPINFOHEADER structure is to cast as a string, like if this for instance :

	pbmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
	pbmi->bmiHeader.biWidth = bmp.bmWidth;
	pbmi->bmiHeader.biHeight = bmp.bmHeight;
	pbmi->bmiHeader.biPlanes = bmp.bmPlanes;
	pbmi->bmiHeader.biBitCount = bmp.bmBitsPixel;

Then i have to send in this manner

send(new_socket, (char*)bmiHeader, messagelen, 0);

Since all others are actually saved inside the structure, not so?

[Niccolo]

@m0mathur,

send defines the second parameter as a void *, it doesn't otherwise "understand" type. It is from the elder "C" interface standards, which typically, in matters like this, uses "void *" as a kind of "catch all" means of sending anything. It sends binary information.

My point is that you should not think of that as a string via char *. The typical standard is to think of char * as a zero terminated array of characters (what we typically think of as a string), which is to say when thought of this way (and especially when functions accept "char *" as a string), the function is likely to stop where the first zero byte is encountered.

That won't happen to send, though. It doesn't care about the content of the data, it just sends the number of bytes you give as length. This is thought of as sending a buffer, whatever form that may be. The receiving side would also receive a void * (if using the same family of functions), which you would then cast to this structure (bmiHeader *) in order to read it as it was sent.

There is an issue that may not actually apply in your situation, but it is about the endianness of the data. Some systems format integers as "big endian", while others (Windows on x86 for example) use "little endian". They are not compatible, and it is therefore common to either send data with the expectation that the recipient must recognize and translate if required, or to transform the data into a "universal" format which avoids the endianness issue. If you know you can restrict the participants to x86 Windows participants, you can reasonably ignore this issue.