Thread: Getting the size of the client recv buffer

No and No.

Both sending and receiving can fragment the message, you have no control over that.

If you call send() with a large buffer, you must look at the return result to see how much was actually sent, and if it's short, then call send() again with the remainder of the buffer until it's all sent.

Likewise with recv(), you can supply a large buffer but recv() won't necessarily wait for it to be filled. Look at the return result to work out how much was received and act accordingly.

If you think it will help, a common technique is to send the message length in front of the message, so you know pretty early on how much data to expect.

Hello Salem, thank's for the reply.

I was thought that maybe there was a getclientbuffersize(). For now I'm using (and I will have to continue using) a variation of the beej guide 'sendall()' function. That's a simulation of a send process that I made for implement the function:

Code:

#include <conio.h>
#include <stdio.h>
#include <stdlib.h>

int send(char* ,int );

int main()
{
FILE *arx;
char *bff=NULL;
int ta,tb,tl,q;
int total,restants,n;
int inc;
bool rm;

arx=fopen("test.txt","rb");
fseek(arx,0L,SEEK_END);
ta=ftell(arx);
fseek(arx,0L,SEEK_SET);

tl=0;
tb=27;
bff=(char*)malloc(sizeof(char)*tb);

inc=0;
rm=false;
while(tl<ta)
    {
    if(rm)
        {
        tb++;
        bff=(char*)realloc(bff,sizeof(char)*tb);
        rm=false;
        }
    
    for(q=0;q<tb;q++)
        {
        //if(feof(arx)!=0) {break;}
        if(tl>=ta) {break;}
        bff[q]=getc(arx);
        tl++;
        }
    bff[q]='\0';
    
    total=0;
    restants=strlen(bff);
    while(total<strlen(bff))
        {
        n=send(bff+total,restants);
        
        if(!rm && n==strlen(bff))
            {
            inc=1;
            rm=true;
            }

        if(n==-1) {break;}
        total+=n;
        restants-=n;
        }
    }

if(bff) {free(bff);}
send(NULL,0);

fclose(arx);
getch();
return 0;
}

int send(char* data,int t)
{
static char complert[1024]="";
int tb,q,bl=0;
char  bff[10];

if(!data) {printf("%s",complert);return 0;}

(t<10) ? tb=t : tb=10;

for(q=0;q<tb;q++)
    {
    bff[q]=data[q];
    bl++;
    }
bff[q]='\0';
sprintf(complert,"%s%s",complert,bff);
return bl;
}
//linked/compiled with mingw & devcpp as a *.cpp

it works with sokets simply using the sokets 'send' function instead my simulation call

Code:

n=send(thesocket,bff+total,restants,0);

the modification is the buffer memory reallocation when the client's buffer is bigger than the server buffer, so I can send more bytes. The method is not completed because the server buffer is reallocated incrementing by 1, so if I could know the client buffer size I would be able to realloc at the exact size to optimze the sending process. Sure that I'm not be the first on think about that...

Feel free to use/modify/comment/criticyze that code I posted

Niara

> #include <conio.h>
The only compiler which needed this header file couldn't do network stuff, so why do you need it?
It's an obsolete header.

> bff=(char*)malloc(sizeof(char)*tb);
Don't cast malloc in C
See the FAQ

Oh now I see
> linked/compiled with mingw & devcpp as a *.cpp
Use a C compiler for your C code then.
Well it's all C except for your use of bool, and that's easy to fix.


> (t<10) ? tb=t : tb=10;
Mmm - if / else would have been clearer, as would
tb = t < 10 ? t : 10;

> sprintf(complert,"%s%s",complert,bff);
Very few C functions (say memmove) work properly if the input and output overlap. Trying to sprintf into the same buffer as you're trying to read from as well is just a recipe for disaster.
Especially as all you needed was strcat()

> bff=(char*)realloc(bff,sizeof(char)*tb);
Classic realloc mis-use.
Always use a temp, and check it for NULL

Code:

temp = realloc ( oldptr, size );
if ( temp ) oldptr = temp;
else // panic

> bff[q]='\0';
You set tb to 10, so when you get here, q is 10
Buffer overflow!