01-09-2009 11:34 AM
I am trying to connect via socket to an HTTP server and send a request and wait for the response, however I am waiting an extremely long time (almost 2 minutes) for a response or getting a timeout.
I know my request to the server is valid because if I open a telnet session in Windows to the same IP/Port and paste the request in the dos prompt window I get the response from the webserver almost immediately. This webserver is a server maintained by Google, so shouldn't have a 2 minute response time.
This is how I am connecting:
socketConnection = (SocketConnection) Connector.open(IP + ":" + Port + ";deviceside=true", Connector.READ_WRITE, false);
dataInputStream = socketConnection.openDataInputStream();
dataOutputStream = socketConnection.openDataOutputStream();
After this I do a blocking read
ret = dataInputStream.read(recvBuffer);
From a different thread I send the request (Is it a problem for a thread to use the DataOutputStream that was opened by another thread?)
dataOutputStream.write(Data, 18, Data.length - 18);
Based on the logs I am printing out, I see there is no exception when sending the data and it completes successfully. However, I'll receive the response sometimes after almost 2 minutes of waiting or will receive a timeout error or Bad socket id error.
The provider I am using is Telus.
Does anyone have any ideas as to why this may be happening?
01-10-2009 10:52 AM
Right now I am testing with a regular HTTP Get request that I extracted from a wireshark log file. This is just a test to confirm everything is working properly. In the future it will be any number of protocols that I will be using which sit on top of TCP. I want to make sure the base is working properly before moving on to different protocols.
01-10-2009 01:01 PM - edited 01-10-2009 01:03 PM
Usually the most direct thing to do is redirect your request to a dummy server
and just print the request. I guess you could step through this in the debugger and
see if there are any threading issues-while you don't have source code to the system classes,
you get method names in the stack trace and you can watch members and locals.
I guess upon re-reading, if you get a response sometimes, you could try closing the output stream and not
just flushing it.