206031 - test client not interactive on windows

Status: RESOLVED FIXED

Description

[Nelson Bolyard (seldom reads bugmail)]

On Unix systems, tstclnt acts like a simple telnet client, allowing interactive
use from the keyboard.  On windows, it doesn't.  On Windows, it reads all 
input from stdin before looking for any response from the server.  This is 
because PR_Poll doesn't work with stdin on Windows.  

tstclnt should be interactive on Windows, too.

Patch forthcoming.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

P3

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Created attachment 123574 [details] [diff] [review]
patch simulates pollable stdin.

This patch uses a socket pair and a separate thread to simulate a pollable
stdin.
The new thread reads from stdin and writes to one socket of the pair.  
The main program thread reads from (and polls) the other socket of the pair,
as a substitute for stdin.   

Please review.

Comment 3

[Wan-Teh Chang]

Comment on attachment 123574 [details] [diff] [review]
patch simulates pollable stdin.

r=wtc.	Some suggested changes.

1. Use WIN32 or _WINDOWS consistently.

2. Use <fcntl.h> and <io.h> instead of "fcntl.h" and "io.h"
because they are standard header files.

3. The -f option is not used with your patch.  Should we
remove it?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I tried removing the -f option and found that the ssl.sh test script uses the
-f option.  We could remove it from that script, but I wonder if any third 
parties also would be affected by removing it.

Comment 5

[Wan-Teh Chang]

Comment on attachment 123574 [details] [diff] [review]
patch simulates pollable stdin.

Nelson, I'm having second thoughts about the part of
this patch that set stdin in binary mode.  tstclnt
always reads text input, so its stdin should remain
in text mode, right?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

When used interactively, stdin will typically be just text.
But when simulating an https POST request, the content can be binary.
In that case, the header includes an explicit length of the data that 
follows.  

The real reason for using binary mode, however, is because http requires
that header lines end in \r\n.  In "text" mode, the \r's will be stripped.
I could try to add them back before copying text to the socketpair, e.g.
calling fgets, and replacing the line endings before writing to the socket.
But this has problems for the aforementioned binary input case.

Perhaps we need something like an "isatty" test for windows.  With stdin
in binary mode, ^Z is no longer recognized as meaning END_OF_FILE. :-(

Here's another thought/question.  Can PR_NewTCPSocketPair fail on windows
client systems that are moderately loaded?  I seem to recall that Windows
attempts to limint the number of listen sockets allowed, except on Windows
server OSes.  With the new call to PR_NewTCPSocketPair, tstclnt requires
server socket permissions on Windows systems that run firewall software 
that only permits the use of listen sockets to approved programs.
Is there another way to simulated a pollable stdin with NSPR without using 
a TCP listen socket?

Comment 7

[Wan-Teh Chang]

Windows limits the backlog queue size of a listening socket
on a non-server flavor of Windows.  I don't know of any
limit that Windows imposes on the number of listen sockets
allowed, but it is possible.

PR_NewTCPSocketPair may trigger a warning on a system running
a personal firewall.  There is no way to simulate a pollable
stdin with NSPR without using a TCP listen socket.  On Windows,
select() only operates on sockets.