Should I close the socket after write()ing to it?

Should I close the socket after write()ing to it?

Post by Fabia » Mon, 26 Oct 1998 03:00:00



Hi everyone !!!!!

I'm writing a little program that logs the activity between the Apache web
server and a web browser (Lynx and Netscape tested).
I'm having problems after sending the data back to the browser.
The browser doesn't display the page until I close the socket (which can't
be done since it should except more requests from the browser)
I've tried several ways of sending the data through the socket but I can't
make it work right ?
What's wrong ?

Socket family :    AF_INET
Socket type    :    SOCK_STREAM

 
 
 

Should I close the socket after write()ing to it?

Post by Michael Ortega-Binderberg » Tue, 27 Oct 1998 04:00:00



Unfortunately YES. If I understand what you're doing,
you have a program that sits between the browse and the server
 doing "something". Like a proxy. (Why you want that is unclear)
Anyway, the HTTP protocol specifies that the way for a client
to know its got the whole page is with closing the socket.
Yes, the header should say how long is the content, Yes, you
can do persistent HTTP which would be more programming and would
let you use the same socket. However, the basic HTTP protocol
specifies that closing the socket is the main cue.

Michael

Quote:>Hi everyone !!!!!
>I'm writing a little program that logs the activity between the Apache web
>server and a web browser (Lynx and Netscape tested).
>I'm having problems after sending the data back to the browser.
>The browser doesn't display the page until I close the socket (which can't
>be done since it should except more requests from the browser)
>I've tried several ways of sending the data through the socket but I can't
>make it work right ?
>What's wrong ?
>Socket family :    AF_INET
>Socket type    :    SOCK_STREAM


 
 
 

Should I close the socket after write()ing to it?

Post by sung-hun, KI » Thu, 29 Oct 1998 04:00:00




> Unfortunately YES. If I understand what you're doing,

> >Socket family :    AF_INET
> >Socket type    :    SOCK_STREAM

But, nph-xx types don't blocking data in Apache web-server.

Use this routine, after socket open.

void nonblock(socket_t s)
{
  int flags;

  flags = fcntl(s, F_GETFL, 0);
  flags |= O_NONBLOCK;
  if (fcntl(s, F_SETFL, flags) < 0) {
    perror("nonblock ");
    exit(-1)
  }

Quote:}

They are same effect "O_NONBLOCK or O_NDELAY" flag in open function.

  ---- Power of the Best!!  ----------------------------------------

   " Tel (053)850-6611,6620, Fax (053)853-2775, PP 015-718-5549 "
 =========================================== Taegu University =======

~

 
 
 

Should I close the socket after write()ing to it?

Post by R S Hai » Fri, 30 Oct 1998 04:00:00



> Hi everyone !!!!!

> I'm writing a little program that logs the activity between the Apache web
> server and a web browser (Lynx and Netscape tested).
> I'm having problems after sending the data back to the browser.
> The browser doesn't display the page until I close the socket (which can't
> be done since it should except more requests from the browser)

Are you sure?  A normal browser doesn't stream requests on a single
connection, it opens a new connection for each request.

So, the accept() call wants to go inside the main loop, and the socket
returned by accept() then wants to be closed inside the loop.  (This
is not the listening socket, which is opened outside the loop and
stays open).

--

 
 
 

Should I close the socket after write()ing to it?

Post by Aaron Cra » Fri, 30 Oct 1998 04:00:00




Quote:> Are you sure?  A normal browser doesn't stream requests on a single
> connection, it opens a new connection for each request.

Define `normal'.  In many situations, the slowest part of retrieving a web
page is the overhead of a TCP setup for each object that's identified by a
URL.  (Think of a page with ump* tiny icons, a couple of hundred bytes
each.)  That's why the HTTP/1.1 protocol supports keep-alives on a transfer.
The client sends a `Connection: keep-alive' header which instructs the
server that if possible, the connection should be kept open and that the
client may well send further requests over the same socket.  The server
responds with either `Connection: keep-alive' if it is possible, or
`Connection: close' if not.  (Typically it won't be possible for
dynamically-generated content, since keep-alives can only work if the server
also sends a Content-Length header.)  There are some more details; see the
HTTP/1.1 protocol definition.

--

 
 
 

Should I close the socket after write()ing to it?

Post by Marc Slemk » Sat, 31 Oct 1998 04:00:00





>> Are you sure?  A normal browser doesn't stream requests on a single
>> connection, it opens a new connection for each request.
>Define `normal'.  In many situations, the slowest part of retrieving a web
>page is the overhead of a TCP setup for each object that's identified by a
>URL.  (Think of a page with ump* tiny icons, a couple of hundred bytes
>each.)  That's why the HTTP/1.1 protocol supports keep-alives on a transfer.

And most clients, even though they only support HTTP/1.0
(eg. Navigator 3.x/4.x, IE 3) still do persistent connections.

Quote:>The client sends a `Connection: keep-alive' header which instructs the
>server that if possible, the connection should be kept open and that the
>client may well send further requests over the same socket.  The server
>responds with either `Connection: keep-alive' if it is possible, or
>`Connection: close' if not.  (Typically it won't be possible for
>dynamically-generated content, since keep-alives can only work if the server
>also sends a Content-Length header.)  There are some more details; see the

No, and that is one of the wins of HTTP/1.1 persistent connections over
Netscape-hacked-on-top-of-1.0-let's-break-the-world ones.  HTTP/1.1
supports (and requires clients to implement) chunking, so you need
no content length header to tell when the content ends.
 
 
 

1. close() a socket that another thread is read()ing

Suppose a thread is doing someessentially

    while ((r = recv (fd, ...)) > 0)
        {
            /* signal that data has been read */
        }
    /* handle errors, some clean-up */

That is, blocking and waiting for data to read. Is it safe (and
portable) to break such a loop with a close() from another thread?

2. 2.4.0 Kernel Panic w/Adaptec 29160

3. write()ing to a blocking socket

4. ET4000w32i with X in 1024x768 help needed

5. threading issue : SIGPIPE => SIG_IGN (writing to closed socket)

6. porting from sunOS to solaris

7. close writing side of socket only in bash

8. installing over network

9. can a socket be closed for reading but open for writing?

10. write failure on closed socket

11. select()/write() does not generate error on a closed socket

12. Forcably closing server sockets and loosing the last write

13. How to solve write to a closed socket then crash.