I'm using Eclipse for an android application. I'm starting two emulators and sending a message between them. There is a server running on both of them and a new message creates a client socket and sends the message over it.
I can't see the message being received by the server. And when I debug step by step, it doesn't proceed after the in.readLine() call, it just says "stepping": http://i.imgur.com/8Jcxl.png (The code you see in the image is the server code).
Can anybody tell me what is happening and what I can do to correct it?
That means that the readLine() method blocks until it finds an EOL character, or the end of the stream has been reached. Make sure the client actually sends an EOL character or closes its socket.
Related
i am using javamail's SMTPTransport.sendMessage method to send emails in my android app and everything works fine... but when i start sending a message and in the middle, i disable my wifi, it gets stuck. I have waited for more than 1hour now and it is still stuck; no exception is thrown... any idea how to handle this situation?
edit:
i have added a timeout
props.put("mail.smtp.connectiontimeout", "3000");
props.put("mail.smtp.timeout", "3000");
does not seem to work ... i have simulated a connection loss and it's already 5mins now and it is still in sending state and has not timed out
edit2:
timeout/error(not even sure if it is a timeout) occurred after 16mins
06-30 18:47:27.722: I/System.out(15906): javax.net.ssl.SSLException: Write error: ssl=0xdf8268: I/O error during system call, Invalid argument
edit 3:
it does not always throw an exception... i have simulated a connection loss and after 1hr, still no exception... it is in sending state..... and have not return yet :(
The current version of JavaMail only handles timeouts for reads, because that's all the JDK supports. For the next JavaMail release I've added support for write timeouts. You can experiment with it using the 1.5.1-SNAPSHOT release of JavaMail available in the maven.java.net repository. You'll need to set the "mail.smtp.writetimeout" property. Don't know if this will help you on Android since it's not really Java...
I have what appears to be a timing problem between a client (Galaxy Nexus) and a custom server since upgrading from Ice Cream Sandwich to Jelly Bean. Here is the general flow:
Client opens socket, issues HTTP get to server
Server accepts, starts new thread, responds with HTTP header and 200 OK.
Server writes (binary) file to socket.
Client reads data from socket and saves to a file.
After server thread writes all data, it closes the socket, and terminates
This has worked well over the past several months prior to the Jelly Bean update. Since the update the binary transfer succeeds about 70% of the time. The remaining 30% fails
when 'serverSocket.getInputStream().read' returns a -1 indicating the end of stream has been reached. No data has been read, no error exceptions raised, nothing in logcat.
The possibility of a timing problem arises when I change the server behavior in step #5. The thread was closing the socket after the write with the observed problems. If I remove the socket close, terminate the thread after the write, and let the OS eventually close the socket then it seems to work all the time.
I used tcpdump and WireShark to look at the packets in both the successful and failed cases. In the failed case a socket is closed in a few milli-seconds while in the successful case the socket is closed is a quarter or more of a second. The net of this is that any delay we cause in the socket closing improves our chances for success.
If anyone has any suggestions with what we may be doing to cause this problem or suggestions on how to narrow down the problem please feel free to respond. I can add code samples if required.
It looks like that when the server ask for the connection close, the socket is immediatly closed. Maybe the default ocket linger's time has changed between version ???
Try setting the socket linger's time using:
socket.setSoLinger(boolean on, int timeout);
to have the server waiting some time before close channel if some data still waiting to be sent.
If this doesn't solve, you can change your flow above to:
...
4.Client reads data from socket and saves to a file.
5.Client send confirmation to server.
6.Server close connection.
--EDITED--
A gracefull way to achive the above without additional TCP data packets traveling for the closing confirmation is:
when server finish writing to the socket calls:
socket.shutdownOutput();
when client socket.read() returns -1, client calls:
socket.close();
This ensures that client is informed that all data has been sent, and sender will wait for the socket closure protocol to complete.
I am having trouble sending a message to a device through the company proxy.
I have done the GCM tutorial on the google site and have successfully registered a device on the google servers with the android emulator,
and also on the server at my end.
For this I had to go through the company proxy, setting it in the access point of the emulator.
Now the problem I have is sending a message from my server to the device through the same proxy.
I am using the servlet code from the demo which uses the
com.google.android.gcm.server.Sender
helper class to send the message.
I am running the servlets on tomcat 7.
I have tried setting the proxy up in the catalina.properties file like so.
http.proxyHost=proxy.company.com
http.proxyPort=8080
And I have tried setting properties inside the servlet itself like below.
System.setProperty("http.proxyHost", "proxy.company.com");
System.setProperty("http.proxyPort", "8080");
But still I get the timeout.
I know its the company proxy because I got the messaging working at home where I have no proxy.
I have seen a proxy object created in the java code and then a connection created with it, but I dont think that is usable here since I am using Sender helper class to send the message.
This is the line that fails in a timeout.
Result result = sender.send(message, registrationId, 5);
Any help would be appreciated.
Regards
Bill
Alright, I finally have it working. In my comment I mentioned that I had succeeded in sending out the message, but the emulator was not recieving it. I had forgotten to follow my own earlier advice and run the emulator from the command line with the proxy parameters set like so:
emulator.exe -avd avd22google -http-proxy proxy.company.com:8080 -debug-proxy
So to summarise, my initial problem was that I had registered the emulator on the with GCM and with my local server, but the when I clicked send message I was getting a timeout.
I initially thought it was the firewall so I did some research and set up the proxy in tomcats catalina.properties file.
This made no difference.
I used the "Charles" web proxy debugger software to see where the message was attempting to be sent to and it came up with https://android.googleapis.com:443
So I initially I added the following to my catalina.properties file:
https.proxyHost=proxy.company.com
https.proxyPort=443
It still did not work. A colleague of mine told me that our company proxy handles all types of requests through port 8080, so I changed the the poort line to:
https.proxyPort=8080
This allowed the message to be sent out.
But then the message was not getting through to the emulator and I was receiving the following error in LogCat.
[GTalkConnection.12] doConnect: caught XMPPError connecting to mtalk.google.com:5228.: -- caused by: java.net.SocketException: The operation timed out
Then I remembered that you need to start the emulator with the command line to get it to use the proxy. Once I did this a flood of messages appeared on my emulator!
So I finally have it working end to end. It's taken me about a week to get GCM fully working within my company firewall, so hopefully this post can help some other poor sod doing this in the future.
cheers
Bill
Having a problem with the android sipdemo timing out when making calls. The native sip client on the phone has no issues calling, works perfect. Its When i initiate the call within the sipdemo i get a timeout in the logcat. timeout is set to standard of 30 seconds.. a local asterisk box is what its connecting to. Registers fine.
I'm having the same problem.
I traced packages in wireshark and here's what I found:
I register to SIP server in SipDemo
I register to SIP server on Desktop (using Ekiga)
I place a call in SipDemo to Ekiga.
INVITE message gets sent to Ekiga
Trying is sent from Ekiga to the server
Ringing is sent from Ekiga to SipDemo
I answer the call on Ekiga client
OK (with session description) is sent from Ekiga to SipDemo. This happens 11 times before Ekiga just gives up
BYE is sent from Ekiga client to SipDemo
Please note that OK is being sent 11 times before Ekiga just gives up and ends the call. This is why the call lasts just 30 seconds.
If you take a look at the RFC here:
http://www.ietf.org/rfc/rfc3261.txt section 13.3.1.4
you can see that the reason Ekiga is giving up on SipDemo client is because it never gets ACK back from SipDemo.
I believe this is android bug, but I can't imagine they could have missed something this basic in their SIP implementation.
In the next few days, I'll try to dig up some answers in android source code...
I'll try see what happens when establishing calls between 2 SipDemo applications. If it works, that means android just ignores ACK all together.
EDIT:
I just tried a call between 2 SipDemo clients. It sends OK 5 times and gives up on the OK, but does not end the call. Interesting behavior :)
EDIT2:
I dug up androids SIP implementation, and I found that ACK should get sent... Even logcat logs this, but I still see nothing in Wireshark. I thought maybe it gets blocked or something, so I ran Shark (like Wireshark for android) on the device, pulled the dump to my laptop, opened it up in Wireshark, and I don't see ACK anywhere. I even looked trough all packets... No filters, just in case I might be filtering it out. Anyways... Here's what I found in android code:
http://hi-android.info/src/com/android/server/sip/SipSessionGroup.java.html
class: SipSessionImpl
method: private boolean outgoingCall(EventObject evt)
in case Response.OK:
you can see this call:
mSipHelper.sendInviteAck(event, mDialog);
In SipHelper, method sendInviteAck, you can see:
if (DEBUG) Log.d(TAG, "send ACK: " + ack);
dialog.sendAck(ack);
Dialog is nist javax.sip, so I don't think there's a need to go further...
I see this message "send ACK" in my logcat when running the application
EDIT3:
I noticed that this issue occurs only with some SIP servers. I now tried opensips, and it works fine. I guess the problem I was having had to do with the server responding to androids keep-alive OPTIONS messages with 404 Not Found. Then, android tried to not use the server as soon as possible. Because of that, as soon as android got the address of its peer client, it tried to send a direct message, and failed
Hard to tell just like that. Try capturing the packages with wireshark, filter for the SIP protocol and have a look at what is sent over the network. Also try it with the native client and compare it to the sipdemo.
Another starting point is the log of your asterisk instance (systemlog)
If you can't figure it out yourself, post the results here.
I am trying to write client for Android which is supposed to communicate with PC server application on local network. Server app is written by my friend in C#. Currently there is an iPhone app that is using this server application with no problems.
I have very simple code for TCP client:
1. Socket s = new Socket(server, port);
2. OutputStream out = s.getOutputStream();
3. PrintWriter output = new PrintWriter(out);
4. output.println("ACTION=Next&VALUE=0&");
5. BufferedReader input = new BufferedReader(new nputStreamReader(s.getInputStream()));
6. String st = input.readLine();
I went through many TCP implementation examples, and they are all similar. Pretty much like my code above. My app freezes on line 6 when I try to read response from the server.
It doesn't cause any errors (no exceptions), nothing shows in debugger, just timeout error after awhile. Server is supposed to return string after executing my action in line 4.
I don't understand why this code hangs. Input is not NULL (I've checked it). I would expect some exception to be thrown or simply empty string to be returned.
So? What am I missing? Could it be problem with some special characters that server app is sending and android can't handle that? Do I need any special permission in my manifest?
I am positive that I have correct IP address and correct port number. I can see that on server application running on my PC.
Thanks.
String st = input.readLine(); Does this command make the program wait until something is being read or it just takes straight whatever is in the buffer. I guess you will need to check continuosly if something came from the server. I mean, you need one infinite loop, something like
While (True){
st = input.readLine();
This will check if anything came the whole time. If u dont use it and if String st = input.readLine(); command doesnt make the program wait, then your code will end without taking anything.
You of course need internet permission in the manifest.
If it were me I'd add instrumentation to the server so that it can tell you when there's been a connection, when that connection has received data, and when a reply is being sent. Or else run tcpdump on the server.
You could also temporarily try grabbing the input character by character rather than a whole line at a time.
Try to figure out how far the "conversation" is progressing so you can figure out where it is really getting stuck