socket send and recv

socket send and recv

[ronkhu]

i have a client program which sends a sequence of bytes everytime 
anything(plus carriage return)  is inputted into STDIN...

but the problem lies in the receiving end of the socket connection...
with a single call of the recv() function, multiple messages sent by the 
client are concatenated into one stream..


    unsigned char msg[] = { 0x00, 0x00, 0x00, 0x20, 0x20, 0x01, 0x00, 
0x00, 0xB2, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 
0x00, 0x20, 0x03, 0x06, 0x03, 0x16, 0x20, 0x10, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF };

        while(1)
        {
            FD_ZERO( &readSet );
            FD_SET( 0, &readSet );
            if ( select( 1, &readSet, NULL, NULL, NULL ) > 0 )
            {
                read( 0, temp, 10 );
                send( sock, msg, 40, 0 ));
            }
        }




because of this scenario, i was forced to add a sequence of bytes that 
would serve as a delimter separating the messages. The server program
would then pre-parsed the message by sub dividing the data using the 
delimeter sequence of bytes

Re: socket send and recv

[Luciano Miguel Ferreira Rocha]

On Thu, Aug 07, 2003 at 06:46:18PM +0800, ronkhu wrote:
> i have a client program which sends a sequence of bytes everytime 
> anything(plus carriage return)  is inputted into STDIN...
> 
> but the problem lies in the receiving end of the socket connection...
> with a single call of the recv() function, multiple messages sent by the 
> client are concatenated into one stream..
Yes, STREAM sockets have no knowledge of messages, but DGRAM do (but
are unreliable).

So you need to have a way to know what is a single message, either by
using delimiters (like \n) or by using headers, with the length of the message.
(Or use DGRAM sockets.)

Also, you can use the TCP_NODELAY socket(7) option to force the data to
be sent immediately, but there's no gaurantee it won't be buffered at the
receiver.

Regards,
Luciano Rocha

Re: socket send and recv

[John T. Williams]

I common delimiter used by many protocols is either a single \n\r for
messages which are known to me less then on line (ie have not \n in them) or
a \n\r.\n\r for messages that could have multiple lines




----- Original Message ----- 
From: "Luciano Miguel Ferreira Rocha" <luciano@lsd.di.uminho.pt>
To: "ronkhu" <ronkhu@ntsp.nec.co.jp>
Cc: "Earl Lapus" <lapuz.rl@mp.ncos.nec.co.jp>; "Lejanson C. Go"
<g_l-go@tmg99.ntes.nec.co.jp>; <linux-c-programming@vger.kernel.org>
Sent: Thursday, August 07, 2003 7:40 AM
Subject: Re: socket send and recv


> On Thu, Aug 07, 2003 at 06:46:18PM +0800, ronkhu wrote:
> > i have a client program which sends a sequence of bytes everytime
> > anything(plus carriage return)  is inputted into STDIN...
> >
> > but the problem lies in the receiving end of the socket connection...
> > with a single call of the recv() function, multiple messages sent by the
> > client are concatenated into one stream..
> Yes, STREAM sockets have no knowledge of messages, but DGRAM do (but
> are unreliable).
>
> So you need to have a way to know what is a single message, either by
> using delimiters (like \n) or by using headers, with the length of the
message.
> (Or use DGRAM sockets.)
>
> Also, you can use the TCP_NODELAY socket(7) option to force the data to
> be sent immediately, but there's no gaurantee it won't be buffered at the
> receiver.
>
> Regards,
> Luciano Rocha
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html