Fw: LibWWW

I am sure people on the list are interested in this feedback. I suspect
that it may be the interactions with the server closing the connection
when libwww doesn't expect it.

Henrik Frystyk Nielsen,
mailto:frystyk@microsoft.com

----- Original Message -----
From: "Judin, Victor" <victor.judin@materna.de>
To: "'Henrik Frystyk Nielsen'" <frystyk@microsoft.com>
Sent: Friday, January 07, 2000 01:32
Subject: AW: LibWWW


I mean, I've encountered it quite oft when direct communicating with the
heavily loaded Netscape server on NT( my client was running on a
multihomed
Solaris Ultra 4 ). To cope with the situation, except the abovementioned
change, I've done the following( I'm not sure that it was all ), if you
like, I'll track all the changes I've done
1) // HTHost_connect
//............
if( !pHost->lock || (pHost->lock == pNet) || ( pHost->channel ==
NULL ))
{
if(( pHost->channel == NULL )&& pHost->lock && (pHost->lock
!= pNet))
{
// That's the consequence - locked HTHost without a
channel
HTHost_killPipe( pHost );
pHost->tcpstate = TCP_BEGIN;
}
//....................
2)//HTDoConnect
//.................
 while (1) {
        switch (me->tcpstate) {
          case TCP_BEGIN:
          {
//......................................
              if (status == HT_PENDING && !net->host->channel )
                return status;
          }
          break;

Victor Judin

> -----Ursprüngliche Nachricht-----
> Von: Henrik Frystyk Nielsen [SMTP:frystyk@microsoft.com]
> Gesendet am: Freitag, 7. Januar 2000 03:41
> An: www-lib@w3.org
> Cc: Judin, Victor
> Betreff: Fw: LibWWW
>
> Is this a common problem?
>
> Henrik Frystyk Nielsen,
> mailto:frystyk@microsoft.com
>
> ----- Original Message -----
> From: "Judin, Victor" <victor.judin@materna.de>
> To: "'Henrik Frystyk Nielsen'" <frystyk@w3.org>
> Sent: Monday, December 27, 1999 06:16
> Subject: LibWWW
>
>
> >
> > Hello Henrik,
> >
> > I've recently examined the LibWWW code , namely
> TReader_read[ HTReader.c ],
> > and following situation seems suspect to me:
> > if HTHost has more than a single HTNet( many pending requests to the
> host ),
> > and the server/proxy sends responses to these requests in a single
TCP
> > packet( for example, 2 responses in a single packet ), which
contains
> more
> > than 1 response, only the first pending HTNet will be callbacked,
the
> rest
> > of TCP packet will be simply discarded, and the corresponding
> request(s)
> > will time out . Can you tell me, if  I'm right, or have I overseen
> > something?
> >
> > Another point: in the same function, if precondition ( me->write >=
> me->read
> > )fails, NETREAD will not be called. Therefore, the user application
> never
> > gets to know, if the far end ( HTHost object which stands in 1:1
> relation to
> > HTReader )has closed the connection( I've seen the situation myself
> with the
> > Netscape server and LibWWW-based client ). As quick-and-dirty
> workaround(
> > signal handling (EINTR) not shown):
> >
> > /*============== HTReader_read================*/
> > /*.............*/
> > fd_set fdR;
> >
> > struct timeval tv = { 0, 0  };/* bail out from select
> > immediately, real select() was called already in HTevtLst.c */
> > /*.............*/
> > FD_CLR( &fdR );
> > FD_SET( soc, &fdR );
> >
> >             if( select( soc + 1, &fdR, NULL, NULL,  &tv ) > 0 )
> >
>
> > #ifdef FIONREAD
> > #ifndef _WINDOWS
> > #define ioctlsocket ioctl
> > #endif
> > /*
> > **  POSIX undocumented but defined on most UNIXes( sun, BSD,..).
> Documented
> > on Windows..
> > */
> >                         int iBufLength = 0;
> >                         if(( ioctlsocket( soc, FIONREAD,
&iBufLength )
> < 0 )
> > || (iBufLength == 0))
> > #else
> > /*
> > ** Don't really remove the byte( MSG_PEEK )
> > */
> >                         char cBuf[ 1 ];
> >                         if ( recv( soc, cBuf, sizeof( cBuf ),
> MSG_PEEK ) ==
> > 0 )
> > #endif
> >                         {
> >                                     EventOrder_add( s,
HTEvent_CLOSE,
> > HTGetTimeInMillies());
> >                                     return HT_CLOSED;
> >                         }
> >            }
> > /*......................*/
> >
> >
> > Merry Christmas!
> >
> > Victor Judin
> >

Received on Monday, 10 January 2000 13:18:29 UTC