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.
Priority: -- → P3
Target Milestone: --- → 3.9
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 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?
Attachment #123574 - Flags: review+
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
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?
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?
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.
You need to log in before you can comment on or make changes to this bug.