Author |
Message |
bigbi #1 / 5
|
tcp sizeof alternative
With unix sockets programming, what is the best way to check the size of a set of data coming in. The data is an array of structs, but on the client side I dont know how many are coming in. My thinking is just to get the total size of bytes that come in and divide by the size of each individual struct. What is the best way to do that. void *buf; bytes = recvfrom(buf); set = bytes / sizeof(struct) ? This will work, but is there a way to get the size of the buffer that comes in. sizeof of course doesnt work. Is there a mem function that checks the size. memcpy, memset, no memsize? or maybe a str function, not strlen. s = mem_size(buf); I would check myself and count all the valid bytes, but this seems cheap.
|
Sun, 03 Apr 2005 02:33:05 GMT |
|
|
David Mean #2 / 5
|
tcp sizeof alternative
Quote:
> With unix sockets programming, what is the best way to check the size of > a set of data coming in. The data is an array of structs, but on the > client side I dont know how many are coming in. My thinking is just to > get the total size of bytes that come in and divide by the size of each > individual struct. What is the best way to do that. > void *buf; > bytes = recvfrom(buf); > set = bytes / sizeof(struct) ? > This will work, but is there a way to get the size of the buffer that > comes in. > sizeof of course doesnt work. Is there a mem function that checks the > size. > memcpy, memset, no memsize? or maybe a str function, not strlen. > s = mem_size(buf); > I would check myself and count all the valid bytes, but this seems > cheap.
You're reading a stream. There's no way of knowing how much data someone is sending (or has sent) you until you receive either 1) a 0 byte read (which means they closed on you), or 2) your find your application protocol end of data marker, or 3) you define in the application protocol a conversation in which they send you the number of bytes to expect. Save case #3, assuming you've kept track of the return value of read(), you'll know exactly how much data you've consumed. Then, it's simply a math problem.
|
Sun, 03 Apr 2005 08:54:50 GMT |
|
|
David Rubi #3 / 5
|
tcp sizeof alternative
[snip - how do you know how much data to read from a socket] Quote: > You're reading a stream. There's no way of knowing how much data someone > is sending (or has sent) you until you receive either 1) a 0 byte read > (which means they closed on you),
Just to clarify to OP, if read[1] *returns* zero, the connection has been closed. You may of course read a zero-byte as part of the data. Quote: > or [...] 3) you define in the application protocol > a conversation in which they send you the number of bytes to expect.
This is typical of most binary protocols. For example, if you send the length of each message as a four-byte integer value, read four bytes, then n bytes, then four bytes, then m bytes, etc. An ASCII (or otherwise text-based protocol) may use '\n' to mark the end of each message, so writing is just a matter of fprintf. david [1] Assuming you use read(), fread(), or a similar function. -- ...the use of keys+commands required a higher level of mental planning to organise the interaction, which apparently obscures the perception of the passage of time... -- forsyth on Tognazzini's "Tog on Interface"
|
Sun, 03 Apr 2005 22:13:39 GMT |
|
|
bigbi #4 / 5
|
tcp sizeof alternative
Quote:
> > With unix sockets programming, what is the best way to check the size of > > a set of data coming in. The data is an array of structs, but on the > > client side I dont know how many are coming in. My thinking is just to > > get the total size of bytes that come in and divide by the size of each > > individual struct. What is the best way to do that. > > void *buf; > > bytes = recvfrom(buf); > > set = bytes / sizeof(struct) ? > > This will work, but is there a way to get the size of the buffer that > > comes in. > > sizeof of course doesnt work. Is there a mem function that checks the > > size. > > memcpy, memset, no memsize? or maybe a str function, not strlen. > > s = mem_size(buf); > > I would check myself and count all the valid bytes, but this seems > > cheap.
> You're reading a stream. There's no way of knowing how much data someone > is sending (or has sent) you until you receive either 1) a 0 byte read > (which means they closed on you), or 2) your find your application > protocol end of data marker, or 3) you define in the application protocol > a conversation in which they send you the number of bytes to expect. > Save case #3, assuming you've kept track of the return value of read(), > you'll know exactly how much data you've consumed. Then, it's simply a > math problem.
Yea, but is there a memory/string function for checking the size of a buffer. Sizeof does structs pretty. I am just looking for the size of an array of structs, that come in through socket.
|
Mon, 04 Apr 2005 00:05:47 GMT |
|
|
Ben Pfaf #5 / 5
|
tcp sizeof alternative
Quote:
> Yea, but is there a memory/string function for checking the size of a > buffer. Sizeof does structs pretty. I am just looking for the size > of an array of structs, that come in through socket.
No, there is no such function. Here are some related FAQs: 7.26: How does free() know how many bytes to free? A: The malloc/free implementation remembers the size of each block as it is allocated, so it is not necessary to remind it of the size when freeing. 7.27: So can I query the malloc package to find out how big an allocated block is? A: Unfortunately, there is no standard or portable way. -- "The fact that there is a holy war doesn't mean that one of the sides doesn't suck - usually both do..." --Alexander Viro
|
Mon, 04 Apr 2005 00:39:50 GMT |
|
|
|