reading socket data

[nix]

Hi ,

I have a query with read call for reading the socket data. From defn
it is read(socket_fd, buffer, BUFSIZE)
Now if I don't know the BUFSIZE? I want to read whenever the data
comes and write this data to a different socket.

My scenario is
I have a socket connection established between two programs (p1 and p2
assuming) running in separate systems. The data which I get on p1 from
p2 will be redirected to a different socket on p1's box and similarly
data coming on p2 from p1 will be redirected to a different socket on
p2's box.
My first question
The size of data is not fixed and I don't know how much I have to
read. How do I handle this in read call?

For redirecting, I guess I have to use write() to write the data
which I have got from read() to a different socket. For writing I can
give write(sock_id,request,strlen(request)); Is this the right way?

thanks

 

[Martin Ambuhl]

From defn
it is read(socket_fd, buffer, BUFSIZE)
Now if I don't know the BUFSIZE?

Strangely enough, of the identifiers in
read(socket_fd, buffer, BUFSIZE);
the only one with a defined meaning in C is BUFSIZE.
Why is the only one which would be in a text for standard C the only one
you don't understand?

BUFSIZ is a constant defined in <stdio.h>, which is an
implemtation-"appropriate" size in bytes for fully buffered I/O on a
stream as initialized by setbuf(). If you want a different sized buffer,
or one with behavior other than that with the mode set to _IOFBF, use
setvbuf() instead. [setbuf() can be used with a (char *)0 for the buffer
argument to turn off buffering, also].

The value of BUFSIZE can be found with a simple program:

#include <stdio.h>

int main(void)
{
/* BUFSIZ should be a size_t since the size argument to
setvbuf() is a size_t, but it might be some unadorned
integral value */
#if defined(__STDC_VERSION__) && __STDC_CERSION__ >= 199901L
printf("BUFSIZE = %zu\n", (size_t) BUFSIZE);
#else
printf("BUFSIZE = %lu\n", (unsigned long) BUFSIZE);
#endif
return 0;
}

 

[Guest]

I have a query with read call for reading the socket data.

sockets aren't on-topic in comp.lang.c so you might be better
off in a unix news group. For instance comp.unix.programmer

From defn
it is read(socket_fd, buffer, BUFSIZE)

now this doesn't look like a definition or a declaration of read().
What else could "defn" mean? This look slike a *call* of read().

Now if I don't know the BUFSIZE?

as another poster says it is defined by the C standard. I'm dubious
whether this is a sensible value to pass to read(), but again ask in
cup for a definitive answer.

I want to read whenever the data
comes and write this data to a different socket.

My scenario is
I have a socket connection established between two programs (p1 and p2
assuming) running in separate systems. The data which I get on p1 from
p2 will be redirected to a different socket on p1's box and similarly
data coming on p2 from p1 will be redirected to a different socket on
p2's box.
My first question
The size of data is not fixed and I don't know how much I have to
read. How do I handle this in read call?

do multiple read() calls 'til you get to the end of your data.
You may need some way of determining the end of the data but that
is outside the realm of C, and of basic socket programming.

For redirecting,  I guess I have to use write() to write the data
which I have got from read() to a different socket. For writing I can
give write(sock_id,request,strlen(request));  Is this the right way?

*looks* fairly sane but ask cup


--
Nick Keighley

"The Real Programmer wants a "you asked for it, you got it"
text editor--complicated, cryptic, powerful, unforgiving,
dangerous. TECO, to be precise."

 

[Guest]

(e-mail address removed) said:





Another poster is wrong. It happens.

oh foo

 

[Guest]

What about read()?

what about read()? It's not standard C but unix if that's what
you're asking.

 

[Chris Dollin]

What about read()?

That also.

 

[Richard]

So read() is off topic then? Someone should tell K&R.

Someone should tell "keighley" to fix his shift key.

 

[CBFalconer]

.... snip ...

BUFSIZ is a constant defined in <stdio.h>, which is an
implemtation-"appropriate" size in bytes for fully buffered I/O
on a stream as initialized by setbuf(). If you want a different
sized buffer, or one with behavior other than that with the mode
set to _IOFBF, use setvbuf() instead. [setbuf() can be used with
a (char *)0 for the buffer argument to turn off buffering, also].

The value of BUFSIZE can be found with a simple program:

Er - this is invalid if (BUFSIZE != BUFSIZ) { ...

 

[CBFalconer]

(e-mail address removed) wrote:
.... snip ...


So read() is off topic then? Someone should tell K&R.

I think you should read K&R2 with greater care.

 

[Martin Ambuhl]

Martin Ambuhl wrote:

Er - this is invalid if (BUFSIZE != BUFSIZ) { ...

Thank you for your comment, timestamped
Date: Tue, 17 Feb 2009 20:08:02 -0500

Happily, my error was pointed out by Richard Heathfield in message
<[email protected]>
timestamped
Tue, 17 Feb 2009 08:21:39 +0000
for which I thanked him in message
<[email protected]>
timestamped
17 Feb 2009 03:39:06 -0500

Even though your comment is correct, it is neither as useful or as
timely as Heathfield's. Nonetheless, I happily accept any corrections.
Thank you.

 

[Guest]

CBFalconer said:




See page 170.

in the chapter entitled "The UNIX System Interface".
So where about's in the C Standard does it appear?

 

[Lew Pitcher]

(e-mail address removed) said:


It doesn't appear in the C Standard, and I didn't claim that it
does. It does appear, however, in K&R2. Furthermore, although I was
unable to verify this, I suspect it also appears in K&R1

Yes, on page 159 ("Chapter 8. The Unix System Interface")

and might therefore reasonably be regarded as part of K&R C,

IMHO, not really.

The chapter begins with the following caveat: "The material in this chapter
is concerned with the interface between C programs and the UNIX operating
system. Since most C users are on UNIX systems, this hould be helpful to a
majority of readers. Even if you use C on an different machine, however,
you should be able to glean more insight into C programming from studying
these examples."

I would take this as K&R's recognition that there were language facilities
added to the core C language to permit it to be used in UNIX, and that
these facilities were not present for other operating systems. This, by my
understanding, would make Chapter 8 more a description of a specific set of
C 'extensions' than a part of the core K&R C language.

which *is*
topical here. Nevertheless, I am not arguing that read() /is/
topical (or the reverse). I am only pointing out that just saying
"I think you should read K&R2 with greater care" is not a
sufficient response in itself.

Agreed

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[CBFalconer]

Richard Heathfield ([email protected]) wrote:
.... snip ...


Agreed

Disagreed. The (unquoted) "tell K&R" comment indicates that the OP
has read K&R very cursorily, if at all. The advice is intended to
be of value to him.

 

[Keith Thompson]

Disagreed. The (unquoted) "tell K&R" comment indicates that the OP
has read K&R very cursorily, if at all. The advice is intended to
be of value to him.

It's valuable advice, bu it hardly addresses the OP's point.

"Eat your vegetables" is also valuable advice.

 

[Richard Bos]

It's valuable advice, bu it hardly addresses the OP's point.

"Eat your vegetables" is also valuable advice.

Not really. Novel recipes for vegetables, those are good advice.

Richard