inter process communication

Hi,

My code about generate requests simulation, I have to send 400 requests from client to server , I used TCP connection but in some times the server waite from client and the client also waite the response from the server ?
should I use inter-process communication between client and server ,How can I implemnt this .

for (int i=0;i<=400)
{
//send object to server

thread.sleep(-1*Math.log(Math.random());

//receive response object from the server

}
I have to generate my requests exponintially.

Thanks:)

What's the problem?
It unlikely that any single computer will handle 400 simultaneous network connections, do you expect them all to work at once?

In general, its more reliable to queue requests in the main thread, and have one or more workers that do the actual network communications. The keeps one request from blocking all others.

The Java concurrency modules have suitable tools to build this.

Thank you very much

If you are doing simulation, do it all in a program you write. You may be able to do 400 requests a second if the calling method and the responding method both reside locally on a machine you own and do not have any exposure to outside network.

You may do a great deal of code testing if the server and the client are both written in the same program for the purpose of doing feasibility studies, ones you wrote yourself and run yourself.

In fact, 4000 requests a second is not infeasible if you do not go to disk, use something from java.util that is classifiyable as Collections to simulate a collection of bytes on disk platter.

Nick is correct, but I tend to write such programs as two separate small pieces of code, then execute both on the same machine.

Separate programs lets you do things like run several instances of the server code, so you can test the queuing system at assorted load levels

I cannot get Pat's response to show in the thread view but yes, we can code them as separated code units. I sortof had the design idea of a single static access method with some tricky but simple logic so that two threads are running and we have to deal with the synchronized and volatile and so on. That accomplishes several things. First,... we get off of other people's hardware and help departments. Second,... we have to work out the access logic and that brings a conceptual understanding of a process running full duplex ( something that is addressed in a grossly inadequate manner in the plethora of books commonly available ) and Thirdly,... we can now do feasiblity studies on how and if the app will scale when an if someone who knows nothing about techie trys to ship the app to a powerful server..,

Pat, note that I cannot see your full counter-response while authoring this. We may have lost OP,... in which case we may direct poster to the server that ships with the sample code.