There is a client, there is a server, and there is an "intermediary" between them . The client connects to the intermediary, the intermediary stupidly takes and transfers the data to the server. The fact is that when the text is transferred (tested on the http \ ftp protocols), the "proxy" program normally transfers data. But when binary ... not sure. He also sends them, but the client program can not recognize the data so to speak. An array of type char is used for transmission. Is it possible that when receiving data, some elements of the array overflow and the data is distorted? MB should use a different data type for the buffer?

I decided to test http, raised the server. I tried to download the file zip 2.9mb. I noticed that when I set the size of the buffer in the "intermediary" to receive 3000 bytes, it downloads 360kb and stops when 64b downloads 2.6mb and stops; when 8b, the browser does not quite understand what is coming to it. The file opens with a solid text, but this sometimes happens on ordinary Internet. Also on the size of the incoming buffer in the "intermediary" noticeable difference in speed. How to be, I do not know. Yes, in SDLNet, as noted, there are functions for writing data to the internetwork format in order to get around big endian \ little endian. But I shook myself on a local host myself. No matter how this should probably be at home, the future should probably be taken care of. I attach project files. Maybe someone will want to understand the code. To compile, you need to download and install SDL and SDL_net .

Project file

Those who are too lazy to download, here are the listings. main.cpp and tcputil.h

Issue resolved

Thanks to alexlz for hint. As a result, the function of receiving transmission look like.

#ifndef tcputil_h #define tcputil_h 1 #include "sdl/SDL.h" #include "sdl/SDL_net.h" const unsigned size=1024; char* getMsg(TCPsocket sock,int &n) { static char buf[size]; n=SDLNet_TCP_Recv(sock,buf,size); /* get the string buffer over the socket */ if(n<0) { if(SDLNet_GetError() && strlen(SDLNet_GetError())) /* sometimes blank! */ printf("SDLNet_TCP_Recv: %s\n", SDLNet_GetError()); //free(*buf); return NULL; } /* return the new buffer */ return buf; } /* send a string buffer over a TCP socket with error checking */ /* returns 0 on any errors, length sent on success */ int putMsg(TCPsocket sock, char *str,int n) { /* send the buffer, with the NULL as well */ if(SDLNet_TCP_Send(sock,str,n)<n) { if(SDLNet_GetError() && strlen(SDLNet_GetError())) /* sometimes blank! */ printf("SDLNet_TCP_Send: %s\n", SDLNet_GetError()); return(0); } /* return the length sent */ return n; } #endif

Well, yes, it was worth removing any printf () as the transfer rate increased to "you do not have time to blink."

  • Thank you so much for the tip. Having wondered about it and the mistake was to use std :: string, the functions were initially taken by char *, but I redid it to std :: string for convenience when I did "chat" and then perepastil .. the code is generally not the point. The bottom line is that this is binary data among which \ 0 occurs when ... derived the size of the received packet and the size that shows strlen (), it turned out that 1024 arrived, for example, and strlen () says 453, and eventually sends 453 bytes, and because of the loss Data file did not come all, when exhibited a small ~ 24b buffer, then the file "reached" more, because there are less losses. - Andrey Tereshkov
  • Thank you very much. - Andrey Tereshkov
  • Great, please, but I did not mean a failure from string, but only the use of a string constructor with two char * parameters and a length (I don’t remember what type it is - something derived from int). Those. type str = string (buf, n); - alexlz

3 answers 3

C ++? std :: string? Receive and sign in receipt. Convert the null-terminated char array (buf) to the string str and wonder why the data disappears after zero? (Hint: the length of the piece received is returned by SDLNet_TCP_Recv)

    It would be more logical to use an array of type BYTE (windows.h) IMHO, this is UNSIGNED CHAR . So it would be prudent. You write:

    It is possible that when receiving data, some elements of the array overflow and the data is distorted.

    No, that would cause a crash in the software component where this very OverFlow would OverFlow . What would have caused the collapse of at least this component, if not the entire system (client-> broker-> server). I advise you to clean up your system. After all, we do not see what you send. Therefore, for example, output the received binary data on the server.

    • The fact is that I do not know what exactly sends the client \ server to each other. When the connection goes to the direct client <-> server, then everything is fine ... and when the client <-> intermediary <-> server is not. Experiments have shown that http \ ftp data normally passes. And from that program is not. About unsigned char try .. - Andrei Tereshkov
    • 2
      @SingleAsen, than BYTE[] sensible unsigned char[] ? - drdaeman

    Perhaps the mediator changes the order of bytes , something like big endian and little endian, so read on this topic a little, it can help.

    • Obviously not it. Then the text would not pass, but it passes. I suspect that the non-7bit-safe intermediary is becoming more earthly. - drdaeman
    • one
      Well, I once wrote a network program, and so I have the text of the norms, and the binary data was inverted. - Roman Goriachevskiy
    • one
      @Roman Goriachevskiy, IMHO you client and server worked on machines with different byte order. In general, it is better to transfer binary data by converting it to the network byte order when sending (htonl (), htons ()) and back to the host byte order when receiving (ntohl (), ntohs ()). But it seems this is not the case here. Why would this proxy reorder the bytes in the stream? How does he know the internal data structure? In fact, it would be good to learn more about the proxy. - avp 6:51 pm