Currently, strsclnt can only make a single short GET HTTP request to the server. There is no way to make a POST request or do anything else that can send a lot of data to the server. We need a way to test client to server throughput and bi-directional throughput. The simplest way to do this might be to have them talk something other than HTTP, ie. a simple byte protocol where each side sends a header with the # of bytes to follow. This may however require using non-blocking sockets to get right if only one side is sending data to avoid deadlocks; or multiple threads per socket (one for each side) with the full-duplex option set, and of course proper synchronization for the close case.
Summary: bi-directional test mode for selfserv and strsclnt → streaming bi-directional test mode for selfserv and strsclnt
Nelson mentioned that the -2 option already has some of the code we need to implement this.
Created attachment 179010 [details] [diff] [review] strsclnt patch This patch is an experiment to attempt to do bidirectional I/O with strsclnt . It also tries to fix the issue where a thread is restarted for each request. The patch has bugs and hangs have been observed with it. But it is a starting point.
Created attachment 179011 [details] [diff] [review] matching selfserv patch Goes together with the strsclnt patch. Also broken .
Alexei, this is the bug we were discussing earlier today. The patch to strsclnt will need to be merged since the threading fixes are part of bugzilla 292151 and will be checked in soon. Right now, the logic contained in these patches to do the HTTP POST request in strsclnt and send large responses in selfserv doesn't work properly. A long stress test will result in all the threads eventually hanging on both sides.
Assignee: saul.edwards.bugs → alexei.volkov.bugs
Target Milestone: 3.10 → 3.11
When this is implemented, there should be a way to configure the size of the requests and responses, ie. HTTP content-length . I would suggest adding a command-line argument for both strsclnt and selfserv. The HTTP content-length header wouldn't necessarily have to be parsed on either the client or server side. The client could just send any data it wants and then call PR_Shutdown() to shut down the send side of the connection. The server could PR_Read until it gets an EOF (0), then start sending, then PR_Close. The client would read the response until EOF . This is what I was trying accomplish in the patches I attached, but something was wrong and needs to be fixed. I have implemented other clients with this approach before, and it worked fine.
QA Contact: bishakhabanerjee → jason.m.reid
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
You need to log in before you can comment on or make changes to this bug.