[android-developers] Re: RC33 Network Problem
Yeah, the behavior definitely changed in RC33, I am still having difficulties to close a socket while the 3G connectivity has been lost. On 19 fév, 03:52, Gil virgildobjans...@gmail.com wrote: Yes, the phone still has the connection to the router however what matters is the status of the TCP socket which needs end-to-end connectivity. Applications need to know when TCP connectivity is lost. Not all TCP based protocols require a response for a request. For example in XMPP you sendkeep-alivepackets to the server the server does not actually respond. Also, sending packets just to see if the TCP connection isaliveis a waste of battery power. It is wrong for a disconnected socket not to throw an IOException when trying to send data as well as when executing a blocking read. It also needs to throw and EOFException when the server disconnects. While this behavior is not in the documentation one would expect the same API behavior in dalvik and JVM from this standpoint. I want to reiterate that prior firmware versions (RC28/maybe RC30 and earlier) exhibited the correct behavior from this standpoint. Even the current emulator works fine by throwing an IOException from a blocking read 20 to 30 seconds after the TCP connection is lost. On Feb 18, 5:28 pm, Justin (Google Employee) j...@google.com wrote: I'm looking into this further, although I'm not sure that this is actually wrong behavior. In terms of the network interface, there is no change when the router loses internet connectivity. The phone is still connected to the router. The only way anything can really deal with this is to have a timeout. If no response is sent in X seconds, assume the remote server died or there is no path to it. While inconvenient, you should be able to extend BufferedInputReader to use this timeout mechanism. Have a timer thread, that if the timer expires and no bytes have been read, throw an exception. I'll look into this further. Cheers, Justin Android Team @ Google On Feb 17, 5:02 pm, Gil virgildobjans...@gmail.com wrote: Can anyone from Google comment on this matter? On Feb 17, 11:42 am, Gil virgildobjans...@gmail.com wrote: I did further testing and I was wrong about one thing: the disconnect is not detected at all (not even after 5 minutes as I said initially). The reason I though that the disconnection was detected after 5 min. is because the W-Fi was going to sleep. If IkeepWi-Fialiveby not allowing the phone to go to sleep the problem is quite evident. I also looked at the GTalk debug messages and it turns out that it has the same problem (it never detects that it is disconnected from the server). On Feb 17, 11:19 am, Gil virgildobjans...@gmail.com wrote: Unfortunately, watching the network state will not always work because it does not account for end-to-end TCP connectivity. The server may crash or its Internet connection may go down and you won't know about it. On Feb 17, 10:05 am, Guillaume Perrot guillaume.p...@gmail.com wrote: Yes it's exactly what happens since RC33. Kinda annoying. I have to close sockets in a separate thread when I receive a connectivity event indicating the network is down or we switched network. This thread becomes zombie most of the time because the socket refuses to close (deadlock with a nativeread). 2009/2/17 Gil virgildobjans...@gmail.com: What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to
[android-developers] Re: RC33 Network Problem
I'm looking into this further, although I'm not sure that this is actually wrong behavior. In terms of the network interface, there is no change when the router loses internet connectivity. The phone is still connected to the router. The only way anything can really deal with this is to have a timeout. If no response is sent in X seconds, assume the remote server died or there is no path to it. While inconvenient, you should be able to extend BufferedInputReader to use this timeout mechanism. Have a timer thread, that if the timer expires and no bytes have been read, throw an exception. I'll look into this further. Cheers, Justin Android Team @ Google On Feb 17, 5:02 pm, Gil virgildobjans...@gmail.com wrote: Can anyone from Google comment on this matter? On Feb 17, 11:42 am, Gil virgildobjans...@gmail.com wrote: I did further testing and I was wrong about one thing: the disconnect is not detected at all (not even after 5 minutes as I said initially). The reason I though that the disconnection was detected after 5 min. is because the W-Fi was going to sleep. If I keep Wi-Fi alive by not allowing the phone to go to sleep the problem is quite evident. I also looked at the GTalk debug messages and it turns out that it has the same problem (it never detects that it is disconnected from the server). On Feb 17, 11:19 am, Gil virgildobjans...@gmail.com wrote: Unfortunately, watching the network state will not always work because it does not account for end-to-end TCP connectivity. The server may crash or its Internet connection may go down and you won't know about it. On Feb 17, 10:05 am, Guillaume Perrot guillaume.p...@gmail.com wrote: Yes it's exactly what happens since RC33. Kinda annoying. I have to close sockets in a separate thread when I receive a connectivity event indicating the network is down or we switched network. This thread becomes zombie most of the time because the socket refuses to close (deadlock with a nativeread). 2009/2/17 Gil virgildobjans...@gmail.com: What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). -- Guillaume Perrot Software Engineer at Ubikod BuddyMob developer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: RC33 Network Problem
Yes, the phone still has the connection to the router however what matters is the status of the TCP socket which needs end-to-end connectivity. Applications need to know when TCP connectivity is lost. Not all TCP based protocols require a response for a request. For example in XMPP you send keep-alive packets to the server the server does not actually respond. Also, sending packets just to see if the TCP connection is alive is a waste of battery power. It is wrong for a disconnected socket not to throw an IOException when trying to send data as well as when executing a blocking read. It also needs to throw and EOFException when the server disconnects. While this behavior is not in the documentation one would expect the same API behavior in dalvik and JVM from this standpoint. I want to reiterate that prior firmware versions (RC28/maybe RC30 and earlier) exhibited the correct behavior from this standpoint. Even the current emulator works fine by throwing an IOException from a blocking read 20 to 30 seconds after the TCP connection is lost. On Feb 18, 5:28 pm, Justin (Google Employee) j...@google.com wrote: I'm looking into this further, although I'm not sure that this is actually wrong behavior. In terms of the network interface, there is no change when the router loses internet connectivity. The phone is still connected to the router. The only way anything can really deal with this is to have a timeout. If no response is sent in X seconds, assume the remote server died or there is no path to it. While inconvenient, you should be able to extend BufferedInputReader to use this timeout mechanism. Have a timer thread, that if the timer expires and no bytes have been read, throw an exception. I'll look into this further. Cheers, Justin Android Team @ Google On Feb 17, 5:02 pm, Gil virgildobjans...@gmail.com wrote: Can anyone from Google comment on this matter? On Feb 17, 11:42 am, Gil virgildobjans...@gmail.com wrote: I did further testing and I was wrong about one thing: the disconnect is not detected at all (not even after 5 minutes as I said initially). The reason I though that the disconnection was detected after 5 min. is because the W-Fi was going to sleep. If I keep Wi-Fi alive by not allowing the phone to go to sleep the problem is quite evident. I also looked at the GTalk debug messages and it turns out that it has the same problem (it never detects that it is disconnected from the server). On Feb 17, 11:19 am, Gil virgildobjans...@gmail.com wrote: Unfortunately, watching the network state will not always work because it does not account for end-to-end TCP connectivity. The server may crash or its Internet connection may go down and you won't know about it. On Feb 17, 10:05 am, Guillaume Perrot guillaume.p...@gmail.com wrote: Yes it's exactly what happens since RC33. Kinda annoying. I have to close sockets in a separate thread when I receive a connectivity event indicating the network is down or we switched network. This thread becomes zombie most of the time because the socket refuses to close (deadlock with a nativeread). 2009/2/17 Gil virgildobjans...@gmail.com: What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read
[android-developers] Re: RC33 Network Problem
I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: RC33 Network Problem
What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: RC33 Network Problem
Yes it's exactly what happens since RC33. Kinda annoying. I have to close sockets in a separate thread when I receive a connectivity event indicating the network is down or we switched network. This thread becomes zombie most of the time because the socket refuses to close (deadlock with a nativeread). 2009/2/17 Gil virgildobjans...@gmail.com: What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). -- Guillaume Perrot Software Engineer at Ubikod BuddyMob developer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: RC33 Network Problem
Unfortunately, watching the network state will not always work because it does not account for end-to-end TCP connectivity. The server may crash or its Internet connection may go down and you won't know about it. On Feb 17, 10:05 am, Guillaume Perrot guillaume.p...@gmail.com wrote: Yes it's exactly what happens since RC33. Kinda annoying. I have to close sockets in a separate thread when I receive a connectivity event indicating the network is down or we switched network. This thread becomes zombie most of the time because the socket refuses to close (deadlock with a nativeread). 2009/2/17 Gil virgildobjans...@gmail.com: What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). -- Guillaume Perrot Software Engineer at Ubikod BuddyMob developer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: RC33 Network Problem
I did further testing and I was wrong about one thing: the disconnect is not detected at all (not even after 5 minutes as I said initially). The reason I though that the disconnection was detected after 5 min. is because the W-Fi was going to sleep. If I keep Wi-Fi alive by not allowing the phone to go to sleep the problem is quite evident. I also looked at the GTalk debug messages and it turns out that it has the same problem (it never detects that it is disconnected from the server). On Feb 17, 11:19 am, Gil virgildobjans...@gmail.com wrote: Unfortunately, watching the network state will not always work because it does not account for end-to-end TCP connectivity. The server may crash or its Internet connection may go down and you won't know about it. On Feb 17, 10:05 am, Guillaume Perrot guillaume.p...@gmail.com wrote: Yes it's exactly what happens since RC33. Kinda annoying. I have to close sockets in a separate thread when I receive a connectivity event indicating the network is down or we switched network. This thread becomes zombie most of the time because the socket refuses to close (deadlock with a nativeread). 2009/2/17 Gil virgildobjans...@gmail.com: What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). -- Guillaume Perrot Software Engineer at Ubikod BuddyMob developer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: RC33 Network Problem
Can anyone from Google comment on this matter? On Feb 17, 11:42 am, Gil virgildobjans...@gmail.com wrote: I did further testing and I was wrong about one thing: the disconnect is not detected at all (not even after 5 minutes as I said initially). The reason I though that the disconnection was detected after 5 min. is because the W-Fi was going to sleep. If I keep Wi-Fi alive by not allowing the phone to go to sleep the problem is quite evident. I also looked at the GTalk debug messages and it turns out that it has the same problem (it never detects that it is disconnected from the server). On Feb 17, 11:19 am, Gil virgildobjans...@gmail.com wrote: Unfortunately, watching the network state will not always work because it does not account for end-to-end TCP connectivity. The server may crash or its Internet connection may go down and you won't know about it. On Feb 17, 10:05 am, Guillaume Perrot guillaume.p...@gmail.com wrote: Yes it's exactly what happens since RC33. Kinda annoying. I have to close sockets in a separate thread when I receive a connectivity event indicating the network is down or we switched network. This thread becomes zombie most of the time because the socket refuses to close (deadlock with a nativeread). 2009/2/17 Gil virgildobjans...@gmail.com: What is disturbing is that event if you try to send data on a socket that is not actually connected (according to the situation I outlined initially) the socket does not throw an IOException. It simply thinks it is still connected. On Feb 17, 7:21 am, Guillaume Perrot guillaume.p...@gmail.com wrote: I had the same problem too. Plus when I loose connectivity, it's nearly impossible not to block on socket.close(); It takes forever in that case. I tried both plain and ssl sockets, same behavior in RC33. On Feb 17, 1:23 am, Marc gram...@gmail.com wrote: I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). -- Guillaume Perrot Software Engineer at Ubikod BuddyMob developer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: RC33 Network Problem
I've seen inconsistent behavior from RC30 on in this regard. The IOException happens anywhere from instantly to five minutes later. It seems like a bug to me. Marc On Feb 16, 2:29 pm, Gil virgildobjans...@gmail.com wrote: I finally got to test some code on the RC33 release and I uncovered a difference in the network code compared to earlier versions and the emulator. I'm using a persistent TLS connection to a server and a BufferedInputStream to read from the socket. The problem is that the read method throws an IOException only 5 minutes after the Wi-Fi connection looses connectivity (I unplug the Internet connection from the router to simulate a connection problem). In RC30 and earlier version as well as the latest emulator version (SDK 1.1) read throws an exception after approximately 30 seconds after the connectivity is lost. My code uses an infinite timeout for read (setSoTimeout(0)). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
