Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I am confused (again) about how we are supposed to handle NI Dormancy. I was told recently by someone at Verizon that we are supposed to close the connection after 30 seconds of inactivity. I though the NI Dormancy did that for us, and all we had to do was to properly check return codes on reads and writes, and implement re-connects if it returns AEE_NET_ERROR.

When I tested on a 1x handset in the lab (A610), it seemed that NI Dormancy did close the connection, but reconnecting often failed. I was told at that time by tech support that there seemed to be a 'problem' with that handset, but now I am wondering....

Am I supposed to implement my own 30 second inactivity timer?

In the general case, BREW apps should do absolutely nothing w.r.t. dormancy, either mobile or network initiated.
In the case of mobile initiated dormancy, BREW will do this after the linger timer expires (e.g. 30 seconds of socket inactivity).
In the case of network initiated dormancy, the service provider can do this whenever they like. In the case of Verizon, it is typically after 20 seconds of no IP packets destined for the device.
In both cases, any TCP connections should remain just fine, and the mobile retains the same IP address and PPP session. Only the CDMA traffic channel goes away, and it will combe back automatically the next time there is a network destined IP packet.
It is true, however, that some early BREW 1.1 devices did not handle network initiated dormancy correctly. I believe there is a FAQ about this, but that server is down for maintenance right now, so I can't double check. For those few devices, there may be some special steps the app needs to take to avoid problems.

In the general case, BREW apps should do absolutely nothing w.r.t. dormancy, either mobile or network initiated.
In the case of mobile initiated dormancy, BREW will do this after the linger timer expires (e.g. 30 seconds of socket inactivity).
In the case of network initiated dormancy, the service provider can do this whenever they like. In the case of Verizon, it is typically after 20 seconds of no IP packets destined for the device.
In both cases, any TCP connections should remain just fine, and the mobile retains the same IP address and PPP session. Only the CDMA traffic channel goes away, and it will combe back automatically the next time there is a network destined IP packet.
It is true, however, that some early BREW 1.1 devices did not handle network initiated dormancy correctly. I believe there is a FAQ about this, but that server is down for maintenance right now, so I can't double check. For those few devices, there may be some special steps the app needs to take to avoid problems.

Quote:Originally posted by kurquhar
In the general case, BREW apps should do absolutely nothing w.r.t. dormancy, either mobile or network initiated.
I am curious, then, as to your opinion of what is on this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2598
Can someone at Qualcomm just clarify if the Client app is
supposed to monitor inactivity?
Really, this is just getting ridiculous, and is tempting me to just ping the server every 5 seconds just to make sure there is no dormant period.

Quote:Originally posted by kurquhar
In the general case, BREW apps should do absolutely nothing w.r.t. dormancy, either mobile or network initiated.
I am curious, then, as to your opinion of what is on this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2598
Can someone at Qualcomm just clarify if the Client app is
supposed to monitor inactivity?
Really, this is just getting ridiculous, and is tempting me to just ping the server every 5 seconds just to make sure there is no dormant period.

Quote:Originally posted by jmiller2
I am curious, then, as to your opinion of what is on this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2598
Which part? I was part of that thread and I don't see the commonality.
Quote:Really, this is just getting ridiculous, and is tempting me to just ping the server every 5 seconds just to make sure there is no dormant period.
For certain devices with older BREW 1.1, you may need to do just that. See the end of this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2158

Quote:Originally posted by jmiller2
I am curious, then, as to your opinion of what is on this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2598
Which part? I was part of that thread and I don't see the commonality.
Quote:Really, this is just getting ridiculous, and is tempting me to just ping the server every 5 seconds just to make sure there is no dormant period.
For certain devices with older BREW 1.1, you may need to do just that. See the end of this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2158

Quote:Originally posted by kurquhar
Which part? I was part of that thread and I don't see the commonality.
From that thread:
"we took the advice of Qualcomm and basically tear down our socket after 30 secs of inactivity (always) using a timer callback."
That implies one is monitoring the inactivity oneself, and not letting the OS do it for you. I know we are supposed to do this when connecting, but the FAQ does not say we need to monitor for 30 secs of inactivity the entire time we are connected.
Quote:
For certain devices with older BREW 1.1, you may need to do just that. See the end of this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2158
It looks like the pings only work if they are server to client. I would need to change this. It looks like roundtrip pings is the way to go though.....if I want it to work accross all phones.

Quote:Originally posted by kurquhar
Which part? I was part of that thread and I don't see the commonality.
From that thread:
"we took the advice of Qualcomm and basically tear down our socket after 30 secs of inactivity (always) using a timer callback."
That implies one is monitoring the inactivity oneself, and not letting the OS do it for you. I know we are supposed to do this when connecting, but the FAQ does not say we need to monitor for 30 secs of inactivity the entire time we are connected.
Quote:
For certain devices with older BREW 1.1, you may need to do just that. See the end of this thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=2158
It looks like the pings only work if they are server to client. I would need to change this. It looks like roundtrip pings is the way to go though.....if I want it to work accross all phones.

Quote:Originally posted by jmiller2
From that thread:
"we took the advice of Qualcomm and basically tear down our socket after 30 secs of inactivity (always) using a timer callback."
That implies one is monitoring the inactivity oneself, and not letting the OS do it for you. I know we are supposed to do this when connecting, but the FAQ does not say we need to monitor for 30 secs of inactivity the entire time we are connected.
I'm not sure why they were given that advice, but it may have been only for a specific device and/or carrier; it is not needed in the general case.
Also, according to the FAQ, the connect timeout issue is only for BREW 1.0.1; it is not needed for BREW 1.1 and later.
Quote:It looks like the pings only work if they are server to client. I would need to change this. It looks like roundtrip pings is the way to go though.....if I want it to work accross all phones.
This is the way it appears for Verizon today, but it is only needed for specific early BREW 1.1 devices.

Quote:Originally posted by jmiller2
From that thread:
"we took the advice of Qualcomm and basically tear down our socket after 30 secs of inactivity (always) using a timer callback."
That implies one is monitoring the inactivity oneself, and not letting the OS do it for you. I know we are supposed to do this when connecting, but the FAQ does not say we need to monitor for 30 secs of inactivity the entire time we are connected.
I'm not sure why they were given that advice, but it may have been only for a specific device and/or carrier; it is not needed in the general case.
Also, according to the FAQ, the connect timeout issue is only for BREW 1.0.1; it is not needed for BREW 1.1 and later.
Quote:It looks like the pings only work if they are server to client. I would need to change this. It looks like roundtrip pings is the way to go though.....if I want it to work accross all phones.
This is the way it appears for Verizon today, but it is only needed for specific early BREW 1.1 devices.

BREW 2.0 devices running over 1xRTT are having this issue. Currently this only applies to the LG6000 - to my knowledge.
the problem is that a TCP FIN packet will never cause the CDMA channel to come up, so your server should know how to handle cases where no ACKS are returned for packets it's pushing to the client.
furthermore - this means that even though your app might have closed the socket, the PPP connection might still be up if this happened during dormancy. And in VZWs case they will tear down a PPP connection after atleast 5 minutes of inactivity (sometimes more).
this wouldn't neccessarily be an issue, BUT.... VZW charges users with minute plans by the PPP time.
workarounds:
1) close the socket before the connection goes dormant. currently in VZW this is 20 secs, so we've used 19 secs and it works fine.
2) send a 'keep-alive' packet right before closing the socket. this brings up the CDMA channel, and the FIN is therefore sent out, and the PPP connection is torn down. (this gives you more control IMO and walso works well on the LG6000)
we've noticed another issue though:
when we close an active socket and then immediately close our applet - if the socket is only closed AFTER the app is closed (since asynchronous) , then the PPP connection still stays up in this case. so you'll need a state machine to avoid this case as well.
a lot of fun....

BREW 2.0 devices running over 1xRTT are having this issue. Currently this only applies to the LG6000 - to my knowledge.
the problem is that a TCP FIN packet will never cause the CDMA channel to come up, so your server should know how to handle cases where no ACKS are returned for packets it's pushing to the client.
furthermore - this means that even though your app might have closed the socket, the PPP connection might still be up if this happened during dormancy. And in VZWs case they will tear down a PPP connection after atleast 5 minutes of inactivity (sometimes more).
this wouldn't neccessarily be an issue, BUT.... VZW charges users with minute plans by the PPP time.
workarounds:
1) close the socket before the connection goes dormant. currently in VZW this is 20 secs, so we've used 19 secs and it works fine.
2) send a 'keep-alive' packet right before closing the socket. this brings up the CDMA channel, and the FIN is therefore sent out, and the PPP connection is torn down. (this gives you more control IMO and walso works well on the LG6000)
we've noticed another issue though:
when we close an active socket and then immediately close our applet - if the socket is only closed AFTER the app is closed (since asynchronous) , then the PPP connection still stays up in this case. so you'll need a state machine to avoid this case as well.
a lot of fun....

We originally architected our app to do a send-receive and then close the socket..then re-open it the next time data was to be sent. While this would work for always closing before dormancy, we abandoned it for several reasons:
1. Poor user experience. If the user has to wait for the initial connect multiple times the overall experience is poor and the delay is long.
2. Reconnect problems. Some phones (T720) have problems reconnecting after disconnects. So the more connect/disconnects in an app the less likely a completed game was for us.
3. depending on the pricing plan, the user might be charged multiple times (potentially) for the same minute since they were often reconnecting again within the same minute.
So we went with pings. Since we are not quite live yet, I cannot tell you that this was accepted by the carriers (yet), but I was told by Verizon that this was ok.
Quote:Originally posted by avisito
BREW 2.0 devices running over 1xRTT are having this issue. Currently this only applies to the LG6000 - to my knowledge.
the problem is that a TCP FIN packet will never cause the CDMA channel to come up, so your server should know how to handle cases where no ACKS are returned for packets it's pushing to the client.
furthermore - this means that even though your app might have closed the socket, the PPP connection might still be up if this happened during dormancy. And in VZWs case they will tear down a PPP connection after atleast 5 minutes of inactivity (sometimes more).
this wouldn't neccessarily be an issue, BUT.... VZW charges users with minute plans by the PPP time.
workarounds:
1) close the socket before the connection goes dormant. currently in VZW this is 20 secs, so we've used 19 secs and it works fine.
2) send a 'keep-alive' packet right before closing the socket. this brings up the CDMA channel, and the FIN is therefore sent out, and the PPP connection is torn down. (this gives you more control IMO and walso works well on the LG6000)
we've noticed another issue though:
when we close an active socket and then immediately close our applet - if the socket is only closed AFTER the app is closed (since asynchronous) , then the PPP connection still stays up in this case. so you'll need a state machine to avoid this case as well.
a lot of fun....

We originally architected our app to do a send-receive and then close the socket..then re-open it the next time data was to be sent. While this would work for always closing before dormancy, we abandoned it for several reasons:
1. Poor user experience. If the user has to wait for the initial connect multiple times the overall experience is poor and the delay is long.
2. Reconnect problems. Some phones (T720) have problems reconnecting after disconnects. So the more connect/disconnects in an app the less likely a completed game was for us.
3. depending on the pricing plan, the user might be charged multiple times (potentially) for the same minute since they were often reconnecting again within the same minute.
So we went with pings. Since we are not quite live yet, I cannot tell you that this was accepted by the carriers (yet), but I was told by Verizon that this was ok.
Quote:Originally posted by avisito
BREW 2.0 devices running over 1xRTT are having this issue. Currently this only applies to the LG6000 - to my knowledge.
the problem is that a TCP FIN packet will never cause the CDMA channel to come up, so your server should know how to handle cases where no ACKS are returned for packets it's pushing to the client.
furthermore - this means that even though your app might have closed the socket, the PPP connection might still be up if this happened during dormancy. And in VZWs case they will tear down a PPP connection after atleast 5 minutes of inactivity (sometimes more).
this wouldn't neccessarily be an issue, BUT.... VZW charges users with minute plans by the PPP time.
workarounds:
1) close the socket before the connection goes dormant. currently in VZW this is 20 secs, so we've used 19 secs and it works fine.
2) send a 'keep-alive' packet right before closing the socket. this brings up the CDMA channel, and the FIN is therefore sent out, and the PPP connection is torn down. (this gives you more control IMO and walso works well on the LG6000)
we've noticed another issue though:
when we close an active socket and then immediately close our applet - if the socket is only closed AFTER the app is closed (since asynchronous) , then the PPP connection still stays up in this case. so you'll need a state machine to avoid this case as well.
a lot of fun....

Quote:Originally posted by jmiller2
We originally architected our app to do a send-receive and then close the socket..then re-open it the next time data was to be sent. While this would work for always closing before dormancy, we abandoned it for several reasons:
1. Poor user experience. If the user has to wait for the initial connect multiple times the overall experience is poor and the delay is long.
2. Reconnect problems. Some phones (T720) have problems reconnecting after disconnects. So the more connect/disconnects in an app the less likely a completed game was for us.
3. depending on the pricing plan, the user might be charged multiple times (potentially) for the same minute since they were often reconnecting again within the same minute.
So we went with pings. Since we are not quite live yet, I cannot tell you that this was accepted by the carriers (yet), but I was told by Verizon that this was ok.
we also found that we were able to wake up the CDMA channel from dormancy with no latency simply by calling ISocket_Write(...). Since the socket is not 'Writable' because it's dormant - no packet is actually sent but the device comes out of dormancy nevertheless. It helps us with BREW 2.0 devices - because we can reliably push a FIN packet to our servers this way with no ping\keep alive packets actually finding their way through...

Quote:Originally posted by jmiller2
We originally architected our app to do a send-receive and then close the socket..then re-open it the next time data was to be sent. While this would work for always closing before dormancy, we abandoned it for several reasons:
1. Poor user experience. If the user has to wait for the initial connect multiple times the overall experience is poor and the delay is long.
2. Reconnect problems. Some phones (T720) have problems reconnecting after disconnects. So the more connect/disconnects in an app the less likely a completed game was for us.
3. depending on the pricing plan, the user might be charged multiple times (potentially) for the same minute since they were often reconnecting again within the same minute.
So we went with pings. Since we are not quite live yet, I cannot tell you that this was accepted by the carriers (yet), but I was told by Verizon that this was ok.
we also found that we were able to wake up the CDMA channel from dormancy with no latency simply by calling ISocket_Write(...). Since the socket is not 'Writable' because it's dormant - no packet is actually sent but the device comes out of dormancy nevertheless. It helps us with BREW 2.0 devices - because we can reliably push a FIN packet to our servers this way with no ping\keep alive packets actually finding their way through...