Article delegate-en/345 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] filters on Win32 (Re: SSLWAY difficulties)
16 Mar 1999 04:47:35 GMT (Yutaka Sato)

On 03/10/99(12:35) I wrote in <_A334@delegate-en.ML_>
 |Also I should have said that I tested this on *WindowsNT* with "-v"
 |option and with sslway.exe and {client,server}-{cert,key}.pem at
 |the current directory, using Netscape Navigator 3.0.3Gold[ja] and
 |Netscape Communicator 4.5[en] on WindowsNT.
 |After DeleGate/5.9.0, in the same environment, I can do this like:
 |> set
 |> dg5_9_0 -v -P443 SERVER=https://server FCL=sslway FSV=sslway
 |This time I noticed that the connection to the server was not made
 |at the first time when I did dialogue with the browser to check new
 |certification (This problem must be fixed).  From next time, after

This problem was fixed in DeleGate/5.9.1.  This was caused
by a trial to read zero size of OOB (out-of-band) data from
the connection with client, which seems be introduced in
DeleGate/5.7.5 to try clear possible OOB during polling of
normal in-band data (at iotimeout.c:xPollIn), but seems make
no good effect, and made bad effect on Win32 causing blocking
reading of data from client after 10 seconds of idle time.
Thus waiting SSLway to finish an initial certification dialogue
for longer than 10 seconds made this bug appear.  So I simply
erased this trial in 5.9.1.

 | |I tried this but it didn't work.  I'm testing under Win98.\
 |using it.  Many problems, beside this one, seems have been caused by
 |the strange behavior of duplicated handles of WinSock between
 |(spawned) processes on Win95/98.  The problem seems that a TCP
 |connection is never disconnected (reset) if a socket duplicated and
 |closed in some order... 

I think I could escape this problem by waiting FCL/FSV processes
to finish in the parent process which invoked those processes
(at delegated.c:call_client1) before the parent itself finishes.
So the above example of SSLway has come to work without problem 
on my Win98 machine.

I know still another problem is left in DeleGate on Win95/98 which
causes blocking in polling pipe input.  This problem appears when
you accessed DeleGate with a internal "response filter", which is
used typically when the built-in "/-/" page of DeleGate is
accessed.  The blocking occurs in windows.c:pollPipe function
since the PeekNamedPipe() function on Win95/98 does not return
with FALSE even when a pipe reached EOF status (no pipe handle/
file descriptor for write left).  I could not yet find the way to
escape this problem, so I made limit to the longest polling time,
at most 15 seconds.  (This problem must be fixed in future)
I'll appreciate if someone tell me the right way to poll (anonymous)
pipe of Win32 detecting EOF on Win95/98.

Yutaka Sato <>   @ @ 
Computer Science Division, Electrotechnical Laboratory      ( - )
1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan            _<   >_

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]