Handling partial recv()s
in [Unix Programming]
|
Prev: Proxy site open your favoraite sites facebook myspace ...etc
Next: And, following a series of proxy sites blocked open any page or download from RapidShare download sites have all accelerated the internet for free
From: Moi on 30 Jun 2010 08:20 On Wed, 30 Jun 2010 10:48:45 +0000, arnuld wrote: > > The point is how to create a recv() like that when you don't know how > much data you are going to receive. I only know the maximum number of > characters I am ever gonna receive. Data does come in fragments on my > socket (as its large, around 1400 characters). > > Any ideas ? Basically, you need a protocol to detect your "message boundaries". The simplest possible protocol would want the "messages" to be terminated by a \n (or \r\n) (check SMTP or HTTP). What such a program does, is effectively while(1) { if (the socket is readable) { read() whatever you can read; store/append it in a buffer; } if (the buffer contains a complete message) { /* check for \n in buffer ... */ extract the message from the buffer; perform some actions on it; } } So you will need some buffering. HTH, AvK
From: Nicolas George on 30 Jun 2010 08:25 Moi wrote in message <77da1$4c2b367a$5350c024$24831(a)cache100.multikabel.net>: > The simplest possible protocol would want the "messages" to be terminated > by a \n That is the simplest to imagine, and to quick-test using telnet-like tools, but this is terribly annoying to implement. I would strongly advise against it in newly designed protocols. Announcing the size of the fields before the payload is much more practical. > (or \r\n) _That_ is just plain masochism.
From: Barry Margolin on 30 Jun 2010 08:51 In article <4c2b37ae$0$29606$426a74cc(a)news.free.fr>, Nicolas George <nicolas$george(a)salle-s.org> wrote: > Moi wrote in message > <77da1$4c2b367a$5350c024$24831(a)cache100.multikabel.net>: > > The simplest possible protocol would want the "messages" to be terminated > > by a \n > > That is the simplest to imagine, and to quick-test using telnet-like tools, > but this is terribly annoying to implement. I would strongly advise against > it in newly designed protocols. Announcing the size of the fields before the > payload is much more practical. Except when the data is generated dynamically, so it's not easy to determine the entire length before you start transmitting. HTTP handles this in two ways: 1. The end of the data is marked by closing the connection. 2. "Chunked" encoding. The data is sent in blocks, each of which is preceded by its size, and a zero-length block marks the end of the message. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: arnuld on 30 Jun 2010 09:05 > On Wed, 30 Jun 2010 14:08:50 +0200, Ersek, Laszlo wrote: > ..SNIP.... > 1. Loop until at least N bytes come in (fixed size header). > > 2. Supposing M >= N bytes arrived, parse the header. The header tells > you (because the sender computed it) how much octets the body will > contain. Let's call that integer B. Yes, the server already sends data in that format. Its sends Content- Length: N in the sending text. Problem is how can I be sure that particular length of data will arrive in recv(). It can come in any of these partial recv()s 1st recv(): Content-L 2nd recv(): ength: 1345 1st recv(): Conte 2nd recv(): -Length: 1234 1st recv(): Content-Length: 2nd recv(): 1234 1st recv(): Content-Leng 2nd recv(): th: 1234 -- www.lispmachine.wordpress.com my email is @ the above blog.
From: Eric Sosman on 30 Jun 2010 09:08
On 6/30/2010 6:48 AM, arnuld wrote: > I searched the archives a lot here and found zero solutions to my > problem. There is a lot of discussion on this subject and almost 99% of > it focuses on "You already know what the length of incoming data is". In > my case I don't. Here is a send() created by Beej to handle partial sends > ()s: > > http://beej.us/guide/bgnet/output/html/multipage/advanced.html#sendall > > #include<sys/types.h> > #include<sys/socket.h> > > int sendall(int s, char *buf, int *len) > { > int total = 0; // how many bytes we've sent > int bytesleft = *len; // how many we have left to send > int n; > > while(total< *len) { > n = send(s, buf+total, bytesleft, 0); > if (n == -1) { break; } > total += n; > bytesleft -= n; > } > > *len = total; // return number actually sent here > > return n==-1?-1:0; // return -1 on failure, 0 on success > } > > > > The point is how to create a recv() like that when you don't know how > much data you are going to receive. I only know the maximum number of > characters I am ever gonna receive. Data does come in fragments on my > socket (as its large, around 1400 characters). > > Any ideas ? As far as I can see, there are two cases: Either you know how much you are going to receive, or you are going to receive as much as is sent until you encounter end-of-input or some other "sentinel" condition. Variations: - Agreement: Messages are five characters long Sender: HELLO Receiver: HEL (not enough) LO (aha! done!) - Agreement: Messages begin with a one-digit length Sender: 5HELLO Receiver: 5H (not enough) ELL (still not enough) O (aha! done!) - Agreement: Messages end with an exclamation point Sender: HELLO! Receiver: HE (no terminator yet) LL (nor yet) O! (aha! done!) - Agreement: Messages are enclosed in balanced angle brackets Sender: <HE<LL>O> Receiver: <HE (one pending) <L (two pending) L> (one pending) O> (aha! done!) - Agreement: Message is everything socket sends Sender: HELLO[fin] Receiver: HEL (still alive) LO (still alive) [fin] (aha! done!) It may help if you think "keyboard" when you read from the socket: How do you know whether the typist has finished, or whether he's about to press another key? You need some kind of prior agreement about how the transmissions are structured. If the socket sends more than one message, you must arrange some convention that divides the "flat" stream of bytes into separable entities. -- Eric Sosman esosman(a)ieee-dot-org.invalid |