It's very common to just have a big recieve buffer (64k say) and use that. If you app has a notion of a maximum message size you can use that instead. If you are using TCP you probably have a fixed-length header that includes the message size and you can read the header first, allocate your buffer, then read the rest of the message.

Quote:Original post by pnroachi need to eceive data through call of rcv function, which also takes the size of received data as one of its parameters. but the thing is that i dunno the size of data i have to receive in advance.

You misunderstand the purpose of that parameter. It is not the size of the recieved data, it's the number of bytes you want to receive. The common way to handle this is to use a large receive buffer and set the len parameter to the size of the buffer.

Two gotchas: you can wind up with more than one packet in the receive buffer and the last packet might be incomplete. It is important for you to have a good packet header that not only identifies each packet, but also tells you how large a packet is in bytes. This will allow you to loop through the buffer, split out multiple packets, and save incomplete packets for the next call to receive.

Yes, that will work. The Forum FAQ mentions this, and other methods.