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

Developer

Forums

Forums:

OK, so I've got all the basics of sockets working on my app, using readable and writeable, using timers to make sure the socket connects, etc...and it works...

But I am running into a problem. In the middle of my game, I will have trouble re-connecting to the server. At that point no matter how I retry (Kill INetMRG and ISocket and re-create, reconnect to different port, etc) the retry does not work. Server gets 0 bytes and reports 10054 errors.

If I power cycle the phone then I can re-connect fine. Otherwise, even exiting the app and coming back in sometimes will not connect.

So, for me, it begs the question..should I NOT be closing and opening sockets all the time and instead just keep the connection open the entire time? It seems wasteful since my game is turn based, and the user may want to take his/her time on their turn (although we do impose a limit).

Any advise on the proper way to do retries would be appreciated.

Are the carriers OK with an open connection for the duration of a game?

Does it cause problems to release and reacquire a socket multiple times?

Which handset are you using (and build #)? Does the same thing happen on the Emulator?
Persistant Connections will not be acceptable to the carrier. Your app can get pulled from the catalog, if it ever gets through TBT or carrier testing.
You should be fine releaseing and reaquireing. I think that is the suggested implementation.

Which handset are you using (and build #)? Does the same thing happen on the Emulator?
Persistant Connections will not be acceptable to the carrier. Your app can get pulled from the catalog, if it ever gets through TBT or carrier testing.
You should be fine releaseing and reaquireing. I think that is the suggested implementation.

Quote:Originally posted by FIFA
Which handset are you using (and build #)? Does the same thing happen on the Emulator?
Persistant Connections will not be acceptable to the carrier. Your app can get pulled from the catalog, if it ever gets through TBT or carrier testing.
You should be fine releaseing and reaquireing. I think that is the suggested implementation.
Good to know.
The problem does not occur in the emulator ever (two emulators playing each other, or emulator and phone).
The problem is sporatic.
I am, of course, hunting for that possible one byte overwrite somewhere that is the classic case for an intermittent problem, but I have found nothing yet....
What is your opinion of negotiating the ability to change the Linger time? I have noticed that while lingering, there is a significant slowdown on the phone....it seems that Linger is a background thread that is fairly expensive CPU-wise.

Quote:Originally posted by FIFA
Which handset are you using (and build #)? Does the same thing happen on the Emulator?
Persistant Connections will not be acceptable to the carrier. Your app can get pulled from the catalog, if it ever gets through TBT or carrier testing.
You should be fine releaseing and reaquireing. I think that is the suggested implementation.
Good to know.
The problem does not occur in the emulator ever (two emulators playing each other, or emulator and phone).
The problem is sporatic.
I am, of course, hunting for that possible one byte overwrite somewhere that is the classic case for an intermittent problem, but I have found nothing yet....
What is your opinion of negotiating the ability to change the Linger time? I have noticed that while lingering, there is a significant slowdown on the phone....it seems that Linger is a background thread that is fairly expensive CPU-wise.

WSAECONNRESET (10054)
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This
normally results if the peer application on the remote host is suddenly
stopped, the host is rebooted, or the remote host uses a hard close (see
setsockopt for more information on the SO_LINGER option on the remote
socket.) This error may also result if a connection was broken due to
keep-alive activity detecting a failure while one or more operations are in
progress. Operations that were in progress fail with WSAENETRESET.
Subsequent operations fail with WSAECONNRESET

WSAECONNRESET (10054)
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This
normally results if the peer application on the remote host is suddenly
stopped, the host is rebooted, or the remote host uses a hard close (see
setsockopt for more information on the SO_LINGER option on the remote
socket.) This error may also result if a connection was broken due to
keep-alive activity detecting a failure while one or more operations are in
progress. Operations that were in progress fail with WSAENETRESET.
Subsequent operations fail with WSAECONNRESET

FIFA,
Not necessarily - persistent connections are OK in some circumstances, and are preferred if you are using 1x. Best to ask the respective carriers for their recommendations.

FIFA,
Not necessarily - persistent connections are OK in some circumstances, and are preferred if you are using 1x. Best to ask the respective carriers for their recommendations.

Quote:Originally posted by radub
WSAECONNRESET (10054)
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This
normally results if the peer application on the remote host is suddenly
stopped, the host is rebooted, or the remote host uses a hard close (see
setsockopt for more information on the SO_LINGER option on the remote
socket.) This error may also result if a connection was broken due to
keep-alive activity detecting a failure while one or more operations are in
progress. Operations that were in progress fail with WSAENETRESET.
Subsequent operations fail with WSAECONNRESET
In this case, though, the 'remote' is the phone, since the error is being reported at the server level. I do have keep alives and a linger set on the server, though, and I do the long socket cleanup
when there is an error.

Quote:Originally posted by radub
WSAECONNRESET (10054)
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This
normally results if the peer application on the remote host is suddenly
stopped, the host is rebooted, or the remote host uses a hard close (see
setsockopt for more information on the SO_LINGER option on the remote
socket.) This error may also result if a connection was broken due to
keep-alive activity detecting a failure while one or more operations are in
progress. Operations that were in progress fail with WSAENETRESET.
Subsequent operations fail with WSAECONNRESET
In this case, though, the 'remote' is the phone, since the error is being reported at the server level. I do have keep alives and a linger set on the server, though, and I do the long socket cleanup
when there is an error.

Quote:Originally posted by Louie
FIFA,
Not necessarily - persistent connections are OK in some circumstances, and are preferred if you are using 1x. Best to ask the respective carriers for their recommendations.
Is there an FAQ that says this? Qualcomm's FAQ seems to specifically omit this type of information (Whether or not to keep one socket open or to open and close it multiple times).

Quote:Originally posted by Louie
FIFA,
Not necessarily - persistent connections are OK in some circumstances, and are preferred if you are using 1x. Best to ask the respective carriers for their recommendations.
Is there an FAQ that says this? Qualcomm's FAQ seems to specifically omit this type of information (Whether or not to keep one socket open or to open and close it multiple times).

I am still wondering if there is something I am missing with cleaning up and preparing for a retry. What concerns me most is that once I get an error, the retry can never again connect.
This makes me think that something is not getting properly reset on the phone.
Is it wrong to release and re-acquire the INetMRG interface when doing retries? They do this in the sockets example...but of course that doesn't mean it is the right thing to do.
By the way, is there anyway to instrument code on the handset? Debug Brew Kernel?

I am still wondering if there is something I am missing with cleaning up and preparing for a retry. What concerns me most is that once I get an error, the retry can never again connect.
This makes me think that something is not getting properly reset on the phone.
Is it wrong to release and re-acquire the INetMRG interface when doing retries? They do this in the sockets example...but of course that doesn't mean it is the right thing to do.
By the way, is there anyway to instrument code on the handset? Debug Brew Kernel?

Zorba,
Quote:
Please note that since each carrier has different guidelines for what an application should and should not do when suspended/resumed, reference to carrier guidelines is advised
and
Quote:
Release Socket connection(s).
If the socket connection(s) are not released, the data call will not be torn down. The associated PPP channel will block the phone from making/receiving voice calls. This is true of current networks, and will change in later generation networks.
From http://www.qualcomm.com/brew/developer/resources/ds/kb/51.html
The problem with the FAQ is that is was written for circuit switched data connections, not packet services such as 1x and EVDO. It is much more desireable to keep the network connection up for packet services as this reduces signalling on the network. In particular, for 1x at least, with a dormancy enabled network, the data session will go dormant after about 20 seconds of innactivity anyway, so you will be able to make/receive voice calls nd not have the overhead of re-establishing the data session when you need it.

Zorba,
Quote:
Please note that since each carrier has different guidelines for what an application should and should not do when suspended/resumed, reference to carrier guidelines is advised
and
Quote:
Release Socket connection(s).
If the socket connection(s) are not released, the data call will not be torn down. The associated PPP channel will block the phone from making/receiving voice calls. This is true of current networks, and will change in later generation networks.
From http://www.qualcomm.com/brew/developer/resources/ds/kb/51.html
The problem with the FAQ is that is was written for circuit switched data connections, not packet services such as 1x and EVDO. It is much more desireable to keep the network connection up for packet services as this reduces signalling on the network. In particular, for 1x at least, with a dormancy enabled network, the data session will go dormant after about 20 seconds of innactivity anyway, so you will be able to make/receive voice calls nd not have the overhead of re-establishing the data session when you need it.

Quote:Originally posted by Louie
Zorba,
and
From http://www.qualcomm.com/brew/developer/resources/ds/kb/51.html
The problem with the FAQ is that is was written for circuit switched data connections, not packet services such as 1x and EVDO. It is much more desireable to keep the network connection up for packet services as this reduces signalling on the network. In particular, for 1x at least, with a dormancy enabled network, the data session will go dormant after about 20 seconds of innactivity anyway, so you will be able to make/receive voice calls nd not have the overhead of re-establishing the data session when you need it.
Yes but isn't that the purpose of the Linger?

Quote:Originally posted by Louie
Zorba,
and
From http://www.qualcomm.com/brew/developer/resources/ds/kb/51.html
The problem with the FAQ is that is was written for circuit switched data connections, not packet services such as 1x and EVDO. It is much more desireable to keep the network connection up for packet services as this reduces signalling on the network. In particular, for 1x at least, with a dormancy enabled network, the data session will go dormant after about 20 seconds of innactivity anyway, so you will be able to make/receive voice calls nd not have the overhead of re-establishing the data session when you need it.
Yes but isn't that the purpose of the Linger?

Does anyone know what Brew's timeout for Read and Readable is? And if so is there any way to change it? I do a send and then immediately go into waiting to receive mode. I am certainly not ever wiating more that 10-20 seconds but perhaps that is too much for brew.

Does anyone know what Brew's timeout for Read and Readable is? And if so is there any way to change it? I do a send and then immediately go into waiting to receive mode. I am certainly not ever wiating more that 10-20 seconds but perhaps that is too much for brew.

There is no built-in timeout for Readable in BREW, and Read always returns immediately. If you don't want to wait indefinitely for your Readable callback to fire, you need to use ISHELL_SetTimer().

There is no built-in timeout for Readable in BREW, and Read always returns immediately. If you don't want to wait indefinitely for your Readable callback to fire, you need to use ISHELL_SetTimer().

OK, here is so more information on what is
specifically happening.
Sometime after many successful connects,
the client tries to do a connect and receives
error 530 in the connect callback.
(0x212 AEE_NET_EADDRREQ). DBGPRINTF shows the same
address I have been connecting to all along so there
should be no address problem.
On the server side, recv reports 10054.
The client then waits and tries to reconnect.
From that point on the client gets a 530 error
every time it tries to connect. And, likewise,
the server reports a 10054 error.
So the server is saying the phone disconnected,
and the phone is saying the addr was incorrect?
Even though the addr must be correct for the server
to even get the error?
If I exit the app sometimes it can reconnect, sometimes not.
If I power cycle the phone it can nearly always reconnect.
The server has implemented SO_REUSEADDR, and
SO_DONTLINGER, and I have tried a host of other
options including setting a linger and keepalives (which
are currently off and unneccessary for me since I do
my own pings when I am connected and waiting anyway).
No changes in server settings seem to make a difference.
Even if I change the architecture to be connected always,
which I could do, there is still the issue of suspend resume
which requires a socket closure and subsequent reconnect.
In the present state, if that resume reconnect failed I would
be hosed.
I guess I'll go back to looking at the server settings again for
a while...perhaps I have missed something...

OK, here is so more information on what is
specifically happening.
Sometime after many successful connects,
the client tries to do a connect and receives
error 530 in the connect callback.
(0x212 AEE_NET_EADDRREQ). DBGPRINTF shows the same
address I have been connecting to all along so there
should be no address problem.
On the server side, recv reports 10054.
The client then waits and tries to reconnect.
From that point on the client gets a 530 error
every time it tries to connect. And, likewise,
the server reports a 10054 error.
So the server is saying the phone disconnected,
and the phone is saying the addr was incorrect?
Even though the addr must be correct for the server
to even get the error?
If I exit the app sometimes it can reconnect, sometimes not.
If I power cycle the phone it can nearly always reconnect.
The server has implemented SO_REUSEADDR, and
SO_DONTLINGER, and I have tried a host of other
options including setting a linger and keepalives (which
are currently off and unneccessary for me since I do
my own pings when I am connected and waiting anyway).
No changes in server settings seem to make a difference.
Even if I change the architecture to be connected always,
which I could do, there is still the issue of suspend resume
which requires a socket closure and subsequent reconnect.
In the present state, if that resume reconnect failed I would
be hosed.
I guess I'll go back to looking at the server settings again for
a while...perhaps I have missed something...

I have several questions/comments which may seem unrelated, but taken in total may shed light on your problem:
[=1]
Please elaborate on "using timers to make sure the socket connects". Timers are not required when using ISOCKET_Connect() - when you get the connect callback either there is an error or the socket is connected and ready for use.
Which device and firmware revision are you seeing this problem on? Which carrier and service plan (e.g. 1x)? There are BREW 1.1 devices that do not handle dormancy properly.
Apps should not change INETMGR_SetLinger() - I believe there is a FAQ on this. Linger is just an idle timer, so if you are seeing CPU load during this time it is something else.
WSAECONNRESET could be due to your server killing a dead connection due to TCP_KEEPALIVE. Dead connections can easily happen when power cycling the phone, or when releasing a socket when dormant.
Always set TCP_KEEPALIVE on your server (see previous), and always use SO_REUSEADDR instead of SO_LINGER on your server (see google).
ISOCKET_Release() is enough to clean up the connection. INETMGR_OpenSocket() is enough to create a new one - but make sure you are checking the return value, as you may be running out of sockets.
There is no need to keep a reference to INetMgr. Simply declare one on the stack, create it, OpenSocket, and then INETMGR_Release().
Error 530 (0x212) is AEE_NET_ETIMEDOUT, not EADDRREQ. This indicates that BREW's TCP stack sent a SYN but did not get a SYN ack nor any ICMP error for 30 seconds. One way to debug this is to use Ethereal (or tcpdump) on your server and ensure that the SYN is getting there.
If you have a particularly lossy link, BREW's TCP may be giving up and resetting the connection, resulting in a WSAECONNRESET at the server. Again, Ethereal is the way to look for this.
Have you considered using UDP instead of TCP? It might be better suited to the communication model your game requires.
[*]Have you considered using HTTP and IWeb()? IWeb() has been designed to manage the connections for you in an efficient and carrier acceptable manner.
[/=1][/]

I have several questions/comments which may seem unrelated, but taken in total may shed light on your problem:
[=1]
Please elaborate on "using timers to make sure the socket connects". Timers are not required when using ISOCKET_Connect() - when you get the connect callback either there is an error or the socket is connected and ready for use.
Which device and firmware revision are you seeing this problem on? Which carrier and service plan (e.g. 1x)? There are BREW 1.1 devices that do not handle dormancy properly.
Apps should not change INETMGR_SetLinger() - I believe there is a FAQ on this. Linger is just an idle timer, so if you are seeing CPU load during this time it is something else.
WSAECONNRESET could be due to your server killing a dead connection due to TCP_KEEPALIVE. Dead connections can easily happen when power cycling the phone, or when releasing a socket when dormant.
Always set TCP_KEEPALIVE on your server (see previous), and always use SO_REUSEADDR instead of SO_LINGER on your server (see google).
ISOCKET_Release() is enough to clean up the connection. INETMGR_OpenSocket() is enough to create a new one - but make sure you are checking the return value, as you may be running out of sockets.
There is no need to keep a reference to INetMgr. Simply declare one on the stack, create it, OpenSocket, and then INETMGR_Release().
Error 530 (0x212) is AEE_NET_ETIMEDOUT, not EADDRREQ. This indicates that BREW's TCP stack sent a SYN but did not get a SYN ack nor any ICMP error for 30 seconds. One way to debug this is to use Ethereal (or tcpdump) on your server and ensure that the SYN is getting there.
If you have a particularly lossy link, BREW's TCP may be giving up and resetting the connection, resulting in a WSAECONNRESET at the server. Again, Ethereal is the way to look for this.
Have you considered using UDP instead of TCP? It might be better suited to the communication model your game requires.
[*]Have you considered using HTTP and IWeb()? IWeb() has been designed to manage the connections for you in an efficient and carrier acceptable manner.
[/=1][/]

First, thanks for your response. I have replied to your
specific questions below.
>Please elaborate on "using timers to make sure the socket >connects". Timers are not required when using >ISOCKET_Connect() - when you get the connect callback either >there is an error or the socket is connected and ready for use.
According to the Qualcomm FAQ, one needs to set a timer because 1.1 has a bug in which it does not always report an error if the socket could not connect. I am not hitting the timeout with this problem.
"t. Why does my connect callback not timeout when service is lost (while attempting to connect) or the server does not respond?
Applicable Releases: 1.0, 1.1, 2.0
This is due to a bug in the BREW version 1.0.1 SDK - connect callback is not invoked under the following circumstances:
Service is lost while connect is being attempted
Server does not respond
As a workaround, you should implement a timer in association with the callback. If the connect callback does not occur in 30 seconds, you should timeout the connection.
"
>Which device and firmware revision are you seeing this problem >on? Which carrier and service plan (e.g. 1x)? There are BREW >1.1 devices that do not handle dormancy properly.
Currently seeing it on T720, Samsung scha530, VX4400.
>Apps should not change INETMGR_SetLinger() - I believe there >is a FAQ on this. Linger is just an idle timer, so if you are seeing >CPU load during this time it is something else.
I am talking about linger on the server side, I am not changing the linger on the phone.
>WSAECONNRESET could be due to your server killing a dead >connection due to TCP_KEEPALIVE. Dead connections can easily >happen when power cycling the phone, or when releasing a >socket when dormant.
Keep alives are off on the server for that reason (seemed to be happening more often with keep alives on but I can try it again...)
>Always set TCP_KEEPALIVE on your server (see previous), and >always use SO_REUSEADDR instead of SO_LINGER on your >server (see google).
See above, I am using SO_REUSEADDR on the server and did turn linger off on the server. Keep alives should be on on the server? Hmm. OK, I will turn it back on.
>ISOCKET_Release() is enough to clean up the connection. >INETMGR_OpenSocket() is enough to create a new one - but >make sure you are checking the return value, as you may be >running out of sockets.
How would I run out if I am only using one? I will double check that I am checking all return values.
>There is no need to keep a reference to INetMgr. Simply declare >one on the stack, create it, OpenSocket, and then >INETMGR_Release().
Does that work better than keeping it around?
>Error 530 (0x212) is AEE_NET_ETIMEDOUT, not EADDRREQ. This >indicates that BREW's TCP stack sent a SYN but did not get a >SYN ack nor any ICMP error for 30 seconds. One way to debug >this is to use Ethereal (or tcpdump) on your server and ensure >that the SYN is getting there.
Not according to my docs. Are you looking at the 1.1 pdf?
My docs have:
------------
1073
Network Error Codes
Network error code equals the base NET_ERROR_BASE(0x200) plus the code from the table.
Error Code Description
AEE_NET_SUCCESS (0) successful operation.
AEE_NET_ERROR (-1) unsuccessful operation.
AEE_NET_WOULDBLOCK (-2)
AEE_STREAM_WOULDBLOCK see AEE_NET_WOULDBLOCK.
AEE_NET_EEOF (+1) end of file.
AEE_NET_EBADF (+2) Invalid socket descriptor.
AEE_NET_EFAULT (+3) Invalid buffer or argument.
AEE_NET_EWOULDBLOCK (+4) Operation would block.
AEE_NET_EAFNOSUPPORT (+5) Address family not supported.
AEE_NET_EPROTOTYPE (+6) Wrong protocol for socket type.
AEE_NET_ESOCKNOSUPPORT (+7) Socket parameter not supported.
AEE_NET_EPROTONOSUPPORT (+8) Protocol not supported.
AEE Error Codes
AEE_NET_EMFILE (+9) No more sockets available for opening.
AEE_NET_EOPNOTSUPP (+10) Operation not supported.
AEE_NET_EADDRINUSE (+11) Address already in use.
AEE_NET_EADDRREQ (+12) Destination address required.
AEE_NET_EINPROGRESS (+13) Connection establishment in progress.
AEE_NET_EISCONN (+14) Connection already established.
AEE_NET_EIPADDRCHANGED (+15) IP address changed, causing TCP reset.
AEE_NET_ENOTCONN (+16) socket not connected.
AEE_NET_ECONNREFUSED (+17) Connection attempt refused.
AEE_NET_ETIMEDOUT (+18) Connection attempt timed out.
AEE_NET_ECONNRESET (+19) Connection reset.
AEE_NET_ECONNABORTED (+20) Connection aborted.
AEE_NET_EPIPE (+21) Broken pipe.
AEE_NET_ENETDOWN (+22) Network subsystem unavailable.
AEE_NET_EMAPP (+23) no more applications available.
AEE_NET_EBADAPP (+24) Invalid application ID.
AEE_NET_SOCKEXIST (+25) there are existing sockets.
AEE_NET_EINVAL (+26) invalid operation.
Error Code Description
------------
>If you have a particularly lossy link, BREW's TCP may be giving >up and resetting the connection, resulting in a >WSAECONNRESET at the server. Again, Ethereal is the way to >look for this.
>Have you considered using UDP instead of TCP? It might be >better suited to the communication model your game requires.
I thought UDP did not work in Brew 1.1.
>Have you considered using HTTP and IWeb()? IWeb() has been >designed to manage the connections for you in an efficient and >carrier acceptable manner.
My understanding is the HTTP is bloated and slow compared to using sockets. I will look into it.
THANKS!!!!!

First, thanks for your response. I have replied to your
specific questions below.
>Please elaborate on "using timers to make sure the socket >connects". Timers are not required when using >ISOCKET_Connect() - when you get the connect callback either >there is an error or the socket is connected and ready for use.
According to the Qualcomm FAQ, one needs to set a timer because 1.1 has a bug in which it does not always report an error if the socket could not connect. I am not hitting the timeout with this problem.
"t. Why does my connect callback not timeout when service is lost (while attempting to connect) or the server does not respond?
Applicable Releases: 1.0, 1.1, 2.0
This is due to a bug in the BREW version 1.0.1 SDK - connect callback is not invoked under the following circumstances:
Service is lost while connect is being attempted
Server does not respond
As a workaround, you should implement a timer in association with the callback. If the connect callback does not occur in 30 seconds, you should timeout the connection.
"
>Which device and firmware revision are you seeing this problem >on? Which carrier and service plan (e.g. 1x)? There are BREW >1.1 devices that do not handle dormancy properly.
Currently seeing it on T720, Samsung scha530, VX4400.
>Apps should not change INETMGR_SetLinger() - I believe there >is a FAQ on this. Linger is just an idle timer, so if you are seeing >CPU load during this time it is something else.
I am talking about linger on the server side, I am not changing the linger on the phone.
>WSAECONNRESET could be due to your server killing a dead >connection due to TCP_KEEPALIVE. Dead connections can easily >happen when power cycling the phone, or when releasing a >socket when dormant.
Keep alives are off on the server for that reason (seemed to be happening more often with keep alives on but I can try it again...)
>Always set TCP_KEEPALIVE on your server (see previous), and >always use SO_REUSEADDR instead of SO_LINGER on your >server (see google).
See above, I am using SO_REUSEADDR on the server and did turn linger off on the server. Keep alives should be on on the server? Hmm. OK, I will turn it back on.
>ISOCKET_Release() is enough to clean up the connection. >INETMGR_OpenSocket() is enough to create a new one - but >make sure you are checking the return value, as you may be >running out of sockets.
How would I run out if I am only using one? I will double check that I am checking all return values.
>There is no need to keep a reference to INetMgr. Simply declare >one on the stack, create it, OpenSocket, and then >INETMGR_Release().
Does that work better than keeping it around?
>Error 530 (0x212) is AEE_NET_ETIMEDOUT, not EADDRREQ. This >indicates that BREW's TCP stack sent a SYN but did not get a >SYN ack nor any ICMP error for 30 seconds. One way to debug >this is to use Ethereal (or tcpdump) on your server and ensure >that the SYN is getting there.
Not according to my docs. Are you looking at the 1.1 pdf?
My docs have:
------------
1073
Network Error Codes
Network error code equals the base NET_ERROR_BASE(0x200) plus the code from the table.
Error Code Description
AEE_NET_SUCCESS (0) successful operation.
AEE_NET_ERROR (-1) unsuccessful operation.
AEE_NET_WOULDBLOCK (-2)
AEE_STREAM_WOULDBLOCK see AEE_NET_WOULDBLOCK.
AEE_NET_EEOF (+1) end of file.
AEE_NET_EBADF (+2) Invalid socket descriptor.
AEE_NET_EFAULT (+3) Invalid buffer or argument.
AEE_NET_EWOULDBLOCK (+4) Operation would block.
AEE_NET_EAFNOSUPPORT (+5) Address family not supported.
AEE_NET_EPROTOTYPE (+6) Wrong protocol for socket type.
AEE_NET_ESOCKNOSUPPORT (+7) Socket parameter not supported.
AEE_NET_EPROTONOSUPPORT (+8) Protocol not supported.
AEE Error Codes
AEE_NET_EMFILE (+9) No more sockets available for opening.
AEE_NET_EOPNOTSUPP (+10) Operation not supported.
AEE_NET_EADDRINUSE (+11) Address already in use.
AEE_NET_EADDRREQ (+12) Destination address required.
AEE_NET_EINPROGRESS (+13) Connection establishment in progress.
AEE_NET_EISCONN (+14) Connection already established.
AEE_NET_EIPADDRCHANGED (+15) IP address changed, causing TCP reset.
AEE_NET_ENOTCONN (+16) socket not connected.
AEE_NET_ECONNREFUSED (+17) Connection attempt refused.
AEE_NET_ETIMEDOUT (+18) Connection attempt timed out.
AEE_NET_ECONNRESET (+19) Connection reset.
AEE_NET_ECONNABORTED (+20) Connection aborted.
AEE_NET_EPIPE (+21) Broken pipe.
AEE_NET_ENETDOWN (+22) Network subsystem unavailable.
AEE_NET_EMAPP (+23) no more applications available.
AEE_NET_EBADAPP (+24) Invalid application ID.
AEE_NET_SOCKEXIST (+25) there are existing sockets.
AEE_NET_EINVAL (+26) invalid operation.
Error Code Description
------------
>If you have a particularly lossy link, BREW's TCP may be giving >up and resetting the connection, resulting in a >WSAECONNRESET at the server. Again, Ethereal is the way to >look for this.
>Have you considered using UDP instead of TCP? It might be >better suited to the communication model your game requires.
I thought UDP did not work in Brew 1.1.
>Have you considered using HTTP and IWeb()? IWeb() has been >designed to manage the connections for you in an efficient and >carrier acceptable manner.
My understanding is the HTTP is bloated and slow compared to using sockets. I will look into it.
THANKS!!!!!

Quote:Originally posted by zorba
First, thanks for your response. I have replied to your
specific questions below.
>Which device and firmware revision are you seeing this problem >on? Which carrier and service plan (e.g. 1x)? There are BREW >1.1 devices that do not handle dormancy properly.
Currently seeing it on T720, Samsung scha530, VX4400.
1x service, or simple IS-95? Dormancy is the key factor here that may be causing you problems.
Quote:
>Always set TCP_KEEPALIVE on your server (see previous), and >always use SO_REUSEADDR instead of SO_LINGER on your >server (see google).
See above, I am using SO_REUSEADDR on the server and did turn linger off on the server. Keep alives should be on on the server? Hmm. OK, I will turn it back on.
To clarify, don't actively turn off linger on the server, just leave it at the default.
Quote:
>ISOCKET_Release() is enough to clean up the connection. >INETMGR_OpenSocket() is enough to create a new one - but >make sure you are checking the return value, as you may be >running out of sockets.
How would I run out if I am only using one? I will double check that I am checking all return values.
ISocket is an abstraction layer, and you can create as many as you like. It delays actual socket creation until it is really needed (e.g. during ISOCKET_Connect()). ISOCKET_Release() causes the underlying socket to begin closing, but it can take several seconds before it is ready for reuse, due to TCP.
Quote:
>There is no need to keep a reference to INetMgr. Simply declare >one on the stack, create it, OpenSocket, and then >INETMGR_Release().
Does that work better than keeping it around?
It depends on whether you need it for someting else (e.g. GetHostByName()). If not, let it go so you don't have to keep track of it.
Quote:
>Error 530 (0x212) is AEE_NET_ETIMEDOUT, not EADDRREQ. This >indicates that BREW's TCP stack sent a SYN but did not get a >SYN ack nor any ICMP error for 30 seconds. One way to debug >this is to use Ethereal (or tcpdump) on your server and ensure >that the SYN is getting there.
Not according to my docs. Are you looking at the 1.1 pdf?
My docs have:
------------
1073
Network Error Codes
Network error code equals the base NET_ERROR_BASE(0x200) plus the code from the table.
Error Code Description
AEE_NET_EADDRREQ (+12) Destination address required.
AEE_NET_ETIMEDOUT (+18) Connection attempt timed out.
------------
0x212 = 0x200 + 18 ;)
Quote:
>If you have a particularly lossy link, BREW's TCP may be giving >up and resetting the connection, resulting in a >WSAECONNRESET at the server. Again, Ethereal is the way to >look for this.
Ethereal logs can be quite useful - please give it a try.
Quote:
>Have you considered using UDP instead of TCP? It might be >better suited to the communication model your game requires.
I thought UDP did not work in Brew 1.1.
AFAIK, it does work fine in 1.1.
Quote:
>Have you considered using HTTP and IWeb()? IWeb() has been >designed to manage the connections for you in an efficient and >carrier acceptable manner.
My understanding is the HTTP is bloated and slow compared to using sockets. I will look into it.
Maybe if you had to implement it yourself, it would not be worth it. But given that IWeb has already done all the hard work, the over the wire overhead is minimal. Many BREW apps have good success with IWeb.

Quote:Originally posted by zorba
First, thanks for your response. I have replied to your
specific questions below.
>Which device and firmware revision are you seeing this problem >on? Which carrier and service plan (e.g. 1x)? There are BREW >1.1 devices that do not handle dormancy properly.
Currently seeing it on T720, Samsung scha530, VX4400.
1x service, or simple IS-95? Dormancy is the key factor here that may be causing you problems.
Quote:
>Always set TCP_KEEPALIVE on your server (see previous), and >always use SO_REUSEADDR instead of SO_LINGER on your >server (see google).
See above, I am using SO_REUSEADDR on the server and did turn linger off on the server. Keep alives should be on on the server? Hmm. OK, I will turn it back on.
To clarify, don't actively turn off linger on the server, just leave it at the default.
Quote:
>ISOCKET_Release() is enough to clean up the connection. >INETMGR_OpenSocket() is enough to create a new one - but >make sure you are checking the return value, as you may be >running out of sockets.
How would I run out if I am only using one? I will double check that I am checking all return values.
ISocket is an abstraction layer, and you can create as many as you like. It delays actual socket creation until it is really needed (e.g. during ISOCKET_Connect()). ISOCKET_Release() causes the underlying socket to begin closing, but it can take several seconds before it is ready for reuse, due to TCP.
Quote:
>There is no need to keep a reference to INetMgr. Simply declare >one on the stack, create it, OpenSocket, and then >INETMGR_Release().
Does that work better than keeping it around?
It depends on whether you need it for someting else (e.g. GetHostByName()). If not, let it go so you don't have to keep track of it.
Quote:
>Error 530 (0x212) is AEE_NET_ETIMEDOUT, not EADDRREQ. This >indicates that BREW's TCP stack sent a SYN but did not get a >SYN ack nor any ICMP error for 30 seconds. One way to debug >this is to use Ethereal (or tcpdump) on your server and ensure >that the SYN is getting there.
Not according to my docs. Are you looking at the 1.1 pdf?
My docs have:
------------
1073
Network Error Codes
Network error code equals the base NET_ERROR_BASE(0x200) plus the code from the table.
Error Code Description
AEE_NET_EADDRREQ (+12) Destination address required.
AEE_NET_ETIMEDOUT (+18) Connection attempt timed out.
------------
0x212 = 0x200 + 18 ;)
Quote:
>If you have a particularly lossy link, BREW's TCP may be giving >up and resetting the connection, resulting in a >WSAECONNRESET at the server. Again, Ethereal is the way to >look for this.
Ethereal logs can be quite useful - please give it a try.
Quote:
>Have you considered using UDP instead of TCP? It might be >better suited to the communication model your game requires.
I thought UDP did not work in Brew 1.1.
AFAIK, it does work fine in 1.1.
Quote:
>Have you considered using HTTP and IWeb()? IWeb() has been >designed to manage the connections for you in an efficient and >carrier acceptable manner.
My understanding is the HTTP is bloated and slow compared to using sockets. I will look into it.
Maybe if you had to implement it yourself, it would not be worth it. But given that IWeb has already done all the hard work, the over the wire overhead is minimal. Many BREW apps have good success with IWeb.

>Dormancy is the key factor here that >may be causing you problems.
Isn't that what keep alives are supposed to solve?
>To clarify, don't actively turn off linger on the server, just leave it >at the default.
Yup, I just took out the code that explicitly turned it on, it is now at the default.
>ISocket is an abstraction layer, and you can create as many as >you like. It delays actual socket creation until it is really needed >(e.g. during ISOCKET_Connect()). ISOCKET_Release() causes >the underlying socket to begin closing, but it can take several >seconds before it is ready for reuse, due to TCP.
Hmm, and is there any way to know when it is ready for reuse?
I did register for the network status message,
INETMGR_OnEvent() perhaps my retries need to wait until
that guy gets a NE_SO_CLOSED.
>quote:
>0x212 = 0x200 + 18
Yup, my mistake.
>Ethereal logs can be quite useful - please give it a try.
I am looking at this now...thanks.
>AFAIK, it (UDP) does work fine in 1.1.
OK, but I am going to keep going with TCP for the moment.
Thanks for your help. I will start looking at the packet dumps tomorrow and see if I can what is really going on on the server.

>Dormancy is the key factor here that >may be causing you problems.
Isn't that what keep alives are supposed to solve?
>To clarify, don't actively turn off linger on the server, just leave it >at the default.
Yup, I just took out the code that explicitly turned it on, it is now at the default.
>ISocket is an abstraction layer, and you can create as many as >you like. It delays actual socket creation until it is really needed >(e.g. during ISOCKET_Connect()). ISOCKET_Release() causes >the underlying socket to begin closing, but it can take several >seconds before it is ready for reuse, due to TCP.
Hmm, and is there any way to know when it is ready for reuse?
I did register for the network status message,
INETMGR_OnEvent() perhaps my retries need to wait until
that guy gets a NE_SO_CLOSED.
>quote:
>0x212 = 0x200 + 18
Yup, my mistake.
>Ethereal logs can be quite useful - please give it a try.
I am looking at this now...thanks.
>AFAIK, it (UDP) does work fine in 1.1.
OK, but I am going to keep going with TCP for the moment.
Thanks for your help. I will start looking at the packet dumps tomorrow and see if I can what is really going on on the server.

Quote:Originally posted by zorba
>Dormancy is the key factor here that >may be causing you problems.
Isn't that what keep alives are supposed to solve?
Nope. TCP_KEEPALIVE is used on a server to detect when a client has gone away (e.g. crash, power off) without gracefully closing the connection (i.e. by sending a FIN packet). The default time between checks is typically on the order of an hour.
Verizon, for example, initiates dormancy after about 45 seconds of inactivity on a device with 1x service. Some early devices with BREW 1.1 do not tolerate network initiated dormancy.

Quote:Originally posted by zorba
>Dormancy is the key factor here that >may be causing you problems.
Isn't that what keep alives are supposed to solve?
Nope. TCP_KEEPALIVE is used on a server to detect when a client has gone away (e.g. crash, power off) without gracefully closing the connection (i.e. by sending a FIN packet). The default time between checks is typically on the order of an hour.
Verizon, for example, initiates dormancy after about 45 seconds of inactivity on a device with 1x service. Some early devices with BREW 1.1 do not tolerate network initiated dormancy.

Quote:Originally posted by kurquhar
Nope. TCP_KEEPALIVE is used on a server to detect when a client has gone away (e.g. crash, power off) without gracefully closing the connection (i.e. by sending a FIN packet). The default time between checks is typically on the order of an hour.
Verizon, for example, initiates dormancy after about 45 seconds of inactivity on a device with 1x service. Some early devices with BREW 1.1 do not tolerate network initiated dormancy.
There won't ever be 45 seconds of inactivity when I am connected. I am either sending or receiving all the time I am socket connected (if I need to wait then I send my own pings).
Of course if brew itself causes the delay then there is really nothing I can do about that.
This problem occurs when I do the connect. Has it been 45 seconds since the last close? - Yes that is very likely.
But how that does that differ from the very first time I connect?
Once the linger times out, I _should_ be in the same state I was when I made the first connection.
When you say, "Some early devices with BREW 1.1 do not tolerate network initiated dormancy."
Can you be more specific about which devices, and what the behaviour is?

Quote:Originally posted by kurquhar
Nope. TCP_KEEPALIVE is used on a server to detect when a client has gone away (e.g. crash, power off) without gracefully closing the connection (i.e. by sending a FIN packet). The default time between checks is typically on the order of an hour.
Verizon, for example, initiates dormancy after about 45 seconds of inactivity on a device with 1x service. Some early devices with BREW 1.1 do not tolerate network initiated dormancy.
There won't ever be 45 seconds of inactivity when I am connected. I am either sending or receiving all the time I am socket connected (if I need to wait then I send my own pings).
Of course if brew itself causes the delay then there is really nothing I can do about that.
This problem occurs when I do the connect. Has it been 45 seconds since the last close? - Yes that is very likely.
But how that does that differ from the very first time I connect?
Once the linger times out, I _should_ be in the same state I was when I made the first connection.
When you say, "Some early devices with BREW 1.1 do not tolerate network initiated dormancy."
Can you be more specific about which devices, and what the behaviour is?

Quote:Originally posted by zorba
Yes but isn't that the purpose of the Linger?
Here is something that you should be clear about linger :
In BREW 1.0 and 1.1, the linger time is the amount of time that the BREW AEE waits to terminate the PPP connection after the device’s last connected socket is closed.
In BREW 1.2, the linger time is the amount of time that the BREW AEE waits before attempting to terminate the PPP connection after the last socket activity. In BREW 1.2, the linger time is started after the last socket activity. If there are no open sockets when the linger time expires, then BREW will terminate the PPP connection. If there is an open socket when the linger time expires, then BREW will do nothing. When the last socket is subsequently closed, the PPP connection will be terminated.
In BREW 2.0.x without BREW-initiated dormancy (OEM dependent configuration to enable BREW to be able to initiate dormancy), the linger time is the same as in BREW 1.2
In BREW 2.0.x with BREW-initiated dormancy, the linger time is the amount of time that the BREW AEE waits to close the CDMA traffic channel after the last socket activity. Whether or not the PPP connection is terminated if there are no open sockets when the linger time expires is OEM dependent.

Quote:Originally posted by zorba
Yes but isn't that the purpose of the Linger?
Here is something that you should be clear about linger :
In BREW 1.0 and 1.1, the linger time is the amount of time that the BREW AEE waits to terminate the PPP connection after the device’s last connected socket is closed.
In BREW 1.2, the linger time is the amount of time that the BREW AEE waits before attempting to terminate the PPP connection after the last socket activity. In BREW 1.2, the linger time is started after the last socket activity. If there are no open sockets when the linger time expires, then BREW will terminate the PPP connection. If there is an open socket when the linger time expires, then BREW will do nothing. When the last socket is subsequently closed, the PPP connection will be terminated.
In BREW 2.0.x without BREW-initiated dormancy (OEM dependent configuration to enable BREW to be able to initiate dormancy), the linger time is the same as in BREW 1.2
In BREW 2.0.x with BREW-initiated dormancy, the linger time is the amount of time that the BREW AEE waits to close the CDMA traffic channel after the last socket activity. Whether or not the PPP connection is terminated if there are no open sockets when the linger time expires is OEM dependent.

Quote:Originally posted by zorba
There won't ever be 45 seconds of inactivity when I am connected. I am either sending or receiving all the time I am socket connected (if I need to wait then I send my own pings).
Of course if brew itself causes the delay then there is really nothing I can do about that.
This problem occurs when I do the connect. Has it been 45 seconds since the last close? - Yes that is very likely.
But how that does that differ from the very first time I connect?
Once the linger times out, I _should_ be in the same state I was when I made the first connection.
When you say, "Some early devices with BREW 1.1 do not tolerate network initiated dormancy."
Can you be more specific about which devices, and what the behaviour is?
Are you noticing the problem on all of your handsets T720, A530 and VX4400 ?
On the handset that you are seeing the problem, does it have 1x service ?
Now here is the thing if your handset is making 1x data call: If you make a connection to server (by connection I mean a persistent connection which is supposed to stay alive until the client/your app. doesn't tear down) from a BREW 1.1 handset and there is a period when your connection is "idle" i.e. you do not have any data activity (idle period > 45 sec : in case of verizon), the network would initiate dormancy at around the 45th sec of idle period ( taking into consideration verizon's ntwk) on the traffic channel. Due to this, the traffic channel is torn down but the PPP is not.
Note: Since its a 1.1 handset, the linger time expiry will not be able to close any open sockets and tear down the traffic channel + PPP as mentioned in my previous post.
On handsets with Brew version 1.1.5.7 and higher, after the network initiates dormancy, any socket operation (read/write) on the socket which was open when network initiated dormancy brings up the traffic channel on its own.
However, the handsets you are working with have BREW version 1.1.5.6 and prior. On these, after a network has initiated dormancy on open socket condition, it becomes necessary to
Release the socket, create a new socket and establish a new connection to the server.
There is a known issue with T720/T730 (with Brew version 1.1.5.6 and prior) that requires you to do the following:
Release the socket (ISOCKET_Release())
- Call INETMGR_SetLinger(5)
- Wait for 5 sec (use ISHELL_SetTimer())
- Call INETMGR_SetLinger(X), where X is the default linger timer in seconds for the handset.This default value is equal to the value of dwNetLinger member variable of AEEDeviceInfo returned by
ISHELL_GetDeviceInfo(). This is necessary to reset the linger time to the default value.
- And then call ISOCKET_Connect() for establishing the connection.

Quote:Originally posted by zorba
There won't ever be 45 seconds of inactivity when I am connected. I am either sending or receiving all the time I am socket connected (if I need to wait then I send my own pings).
Of course if brew itself causes the delay then there is really nothing I can do about that.
This problem occurs when I do the connect. Has it been 45 seconds since the last close? - Yes that is very likely.
But how that does that differ from the very first time I connect?
Once the linger times out, I _should_ be in the same state I was when I made the first connection.
When you say, "Some early devices with BREW 1.1 do not tolerate network initiated dormancy."
Can you be more specific about which devices, and what the behaviour is?
Are you noticing the problem on all of your handsets T720, A530 and VX4400 ?
On the handset that you are seeing the problem, does it have 1x service ?
Now here is the thing if your handset is making 1x data call: If you make a connection to server (by connection I mean a persistent connection which is supposed to stay alive until the client/your app. doesn't tear down) from a BREW 1.1 handset and there is a period when your connection is "idle" i.e. you do not have any data activity (idle period > 45 sec : in case of verizon), the network would initiate dormancy at around the 45th sec of idle period ( taking into consideration verizon's ntwk) on the traffic channel. Due to this, the traffic channel is torn down but the PPP is not.
Note: Since its a 1.1 handset, the linger time expiry will not be able to close any open sockets and tear down the traffic channel + PPP as mentioned in my previous post.
On handsets with Brew version 1.1.5.7 and higher, after the network initiates dormancy, any socket operation (read/write) on the socket which was open when network initiated dormancy brings up the traffic channel on its own.
However, the handsets you are working with have BREW version 1.1.5.6 and prior. On these, after a network has initiated dormancy on open socket condition, it becomes necessary to
Release the socket, create a new socket and establish a new connection to the server.
There is a known issue with T720/T730 (with Brew version 1.1.5.6 and prior) that requires you to do the following:
Release the socket (ISOCKET_Release())
- Call INETMGR_SetLinger(5)
- Wait for 5 sec (use ISHELL_SetTimer())
- Call INETMGR_SetLinger(X), where X is the default linger timer in seconds for the handset.This default value is equal to the value of dwNetLinger member variable of AEEDeviceInfo returned by
ISHELL_GetDeviceInfo(). This is necessary to reset the linger time to the default value.
- And then call ISOCKET_Connect() for establishing the connection.

"Are you noticing the problem on all of your handsets T720, A530 and VX4400 ?"
Yes
"On the handset that you are seeing the problem, does it have 1x service ?:
A530 is definately 1x and manifests the problem. I will check on the others.
"Now here is the thing if your handset is making 1x data call: If you make a connection to server (by connection I mean a persistent connection which is supposed to stay alive until the client/your app. doesn't tear down) from a BREW 1.1 handset and there is a period when your connection is "idle" i.e. you do not have any data activity (idle period > 45 sec : in case of verizon), the network would initiate dormancy at around the 45th sec of idle period ( taking into consideration verizon's ntwk) on the traffic channel. Due to this, the traffic channel is torn down but the PPP is not. "
Since I do my own pings, I am never connected with that long a period of inactivity. When this problem occurs it happens when a new connect is attempted. The socket has been closed and released and the app has been doing other things for some period of time. (Might be within the linger time might not)
I attempt to connect by creating a new socket, and get the error 530.
"However, the handsets you are working with have BREW version 1.1.5.6 and prior. On these, after a network has initiated dormancy on open socket condition, it becomes necessary to
Release the socket, create a new socket and establish a new connection to the server."
My error occurs on a ISocket connect attempt.
Not during an active connection. The new connection never gets to be active or send any data. The server issues an accept, but the client gets a 530 and then starts closing the socket to get a retry. When the socket is closed it waits a second or two and tries again with the same result -- error 530. At that point the only thing that seems to let that phone reconnect to the server is to power cycle it (although sometimes exiting the app will allow the connect also) Both of the aformentioned are obvisouly less than ideal for my application.
"There is a known issue with T720/T730 (with Brew version 1.1.5.6 and prior) that requires you to do the following:
Release the socket (ISOCKET_Release())
- Call INETMGR_SetLinger(5)
- Wait for 5 sec (use ISHELL_SetTimer())
- Call INETMGR_SetLinger(X), where X is the default linger timer in seconds for the handset.This default value is equal to the value of dwNetLinger member variable of AEEDeviceInfo returned by
ISHELL_GetDeviceInfo(). This is necessary to reset the linger time to the default value.
- And then call ISOCKET_Connect() for establishing the connection."
Requires me to do that when? When closing a connection?
When receiving an error?
Is this why when I try to open a new connection after getting an error it fails with a timeout? Is it ok to do this on other phones ?
(Brew doesn't seem to provide a way to identify what phone you are on).
Are the any other Brew 1.1 phone specific issues with ISocket?
Is there an FAQ on phone specific issues up on Qualcomm's extranet?
adv-THANKS-ance

"Are you noticing the problem on all of your handsets T720, A530 and VX4400 ?"
Yes
"On the handset that you are seeing the problem, does it have 1x service ?:
A530 is definately 1x and manifests the problem. I will check on the others.
"Now here is the thing if your handset is making 1x data call: If you make a connection to server (by connection I mean a persistent connection which is supposed to stay alive until the client/your app. doesn't tear down) from a BREW 1.1 handset and there is a period when your connection is "idle" i.e. you do not have any data activity (idle period > 45 sec : in case of verizon), the network would initiate dormancy at around the 45th sec of idle period ( taking into consideration verizon's ntwk) on the traffic channel. Due to this, the traffic channel is torn down but the PPP is not. "
Since I do my own pings, I am never connected with that long a period of inactivity. When this problem occurs it happens when a new connect is attempted. The socket has been closed and released and the app has been doing other things for some period of time. (Might be within the linger time might not)
I attempt to connect by creating a new socket, and get the error 530.
"However, the handsets you are working with have BREW version 1.1.5.6 and prior. On these, after a network has initiated dormancy on open socket condition, it becomes necessary to
Release the socket, create a new socket and establish a new connection to the server."
My error occurs on a ISocket connect attempt.
Not during an active connection. The new connection never gets to be active or send any data. The server issues an accept, but the client gets a 530 and then starts closing the socket to get a retry. When the socket is closed it waits a second or two and tries again with the same result -- error 530. At that point the only thing that seems to let that phone reconnect to the server is to power cycle it (although sometimes exiting the app will allow the connect also) Both of the aformentioned are obvisouly less than ideal for my application.
"There is a known issue with T720/T730 (with Brew version 1.1.5.6 and prior) that requires you to do the following:
Release the socket (ISOCKET_Release())
- Call INETMGR_SetLinger(5)
- Wait for 5 sec (use ISHELL_SetTimer())
- Call INETMGR_SetLinger(X), where X is the default linger timer in seconds for the handset.This default value is equal to the value of dwNetLinger member variable of AEEDeviceInfo returned by
ISHELL_GetDeviceInfo(). This is necessary to reset the linger time to the default value.
- And then call ISOCKET_Connect() for establishing the connection."
Requires me to do that when? When closing a connection?
When receiving an error?
Is this why when I try to open a new connection after getting an error it fails with a timeout? Is it ok to do this on other phones ?
(Brew doesn't seem to provide a way to identify what phone you are on).
Are the any other Brew 1.1 phone specific issues with ISocket?
Is there an FAQ on phone specific issues up on Qualcomm's extranet?
adv-THANKS-ance

Quote:
Since I do my own pings, I am never connected with that long a period of inactivity.
Are your pings round-trip? IOW, does your server respond or ignore the ping packet? How many bytes long are your ping packets?
The reason I ask these questions is that we have found that TCP "pings" are a very ineffective method for staving off network initiated dormany in (at least) Verizon, for the following reasons:
[=1]
Writing a few bytes to a TCP socket does not guarantee that any IP traffic is generated right away. This is due to Nagle's algorithm, which attempts to minimize the number of small packets in the network (see google).
[*]For some unknown reason, Verizon only uses traffic going towards the phone to reset its dormancy timer - they ignore one way traffic from the phone.
[/=1]
We have had better luck using a second UDP socket to bounce a small packet off of an echo server every 15 seconds or so.[/]

Quote:
Since I do my own pings, I am never connected with that long a period of inactivity.
Are your pings round-trip? IOW, does your server respond or ignore the ping packet? How many bytes long are your ping packets?
The reason I ask these questions is that we have found that TCP "pings" are a very ineffective method for staving off network initiated dormany in (at least) Verizon, for the following reasons:
[=1]
Writing a few bytes to a TCP socket does not guarantee that any IP traffic is generated right away. This is due to Nagle's algorithm, which attempts to minimize the number of small packets in the network (see google).
[*]For some unknown reason, Verizon only uses traffic going towards the phone to reset its dormancy timer - they ignore one way traffic from the phone.
[/=1]
We have had better luck using a second UDP socket to bounce a small packet off of an echo server every 15 seconds or so.[/]

"On the handset that you are seeing the problem, does it have 1x service ?:
A530 is definately 1x and manifests the problem. I will check on the others.
As per our information, A530 has not been launched with 1x service by Verizon. I may be wrong and would like to get a confirmation from your end.
My error occurs on a ISocket connect attempt.
Not during an active connection.
The issue on Brew 1.1.5.6 and prior handsets on 1x service IS with ISocket connect attempt. Because the previous connection during idle period was torn down by network initiated dormancy, the next connect attempt is not successful. As mentioned previously, on handsets other than T720/T730, it can be solved by releasing the previous socket, creating a new socket and attempting a connection.
Requires me to do that when? When closing a connection?
When receiving an error?
Is this why when I try to open a new connection after getting an error it fails with a timeout? Is it ok to do this on other phones ?
(Brew doesn't seem to provide a way to identify what phone you are on).
As mentioned previously, you need to do this when you are trying to connect to your server after your previous connection was affected by NI dormancy. This is specific to T720./T730 and is also mentioned on the DDS.
==============================================
Having said all this, you should rather check if your handsets are actually making 1x data calls. If its not then you should not have to dwell into these issue. Instead, there must be some bug with your app. or your server configuration causing the problem.

"On the handset that you are seeing the problem, does it have 1x service ?:
A530 is definately 1x and manifests the problem. I will check on the others.
As per our information, A530 has not been launched with 1x service by Verizon. I may be wrong and would like to get a confirmation from your end.
My error occurs on a ISocket connect attempt.
Not during an active connection.
The issue on Brew 1.1.5.6 and prior handsets on 1x service IS with ISocket connect attempt. Because the previous connection during idle period was torn down by network initiated dormancy, the next connect attempt is not successful. As mentioned previously, on handsets other than T720/T730, it can be solved by releasing the previous socket, creating a new socket and attempting a connection.
Requires me to do that when? When closing a connection?
When receiving an error?
Is this why when I try to open a new connection after getting an error it fails with a timeout? Is it ok to do this on other phones ?
(Brew doesn't seem to provide a way to identify what phone you are on).
As mentioned previously, you need to do this when you are trying to connect to your server after your previous connection was affected by NI dormancy. This is specific to T720./T730 and is also mentioned on the DDS.
==============================================
Having said all this, you should rather check if your handsets are actually making 1x data calls. If its not then you should not have to dwell into these issue. Instead, there must be some bug with your app. or your server configuration causing the problem.

"As per our information, A530 has not been launched with 1x service by Verizon. I may be wrong and would like to get a confirmation from your end. "
OK, I am going by the little 1x icon that appears on the phone.
I will check more into this.
"The issue on Brew 1.1.5.6 and prior handsets on 1x service IS with ISocket connect attempt. Because the previous connection during idle period was torn down by network initiated dormancy, the next connect attempt is not successful. As mentioned previously, on handsets other than T720/T730, it can be solved by releasing the previous socket, creating a new socket and attempting a connection."
OK, but I am doing a release and close myself BEFORE I try the reconnect every time. I do this dozens of times with no problem. But when one fails all subsequent ones fail. Are you talking about Brew's internal socket connection? Meaning the one that stay open during the linger?
"Having said all this, you should rather check if your handsets are actually making 1x data calls. If its not then you should not have to dwell into these issue. Instead, there must be some bug with your app. or your server configuration causing the problem."
I have someone checking on this. Any hints as to how I can find out easily while I am waiting?
This also brings up another issue. How can I tell this at run-time?
My customer will buy their phone and have or not have this service. I want my code to work either way. THis is why I asked if there was any harm in doing the 5 second linger thing as a general practice.
I am going to test with this 5 sec linger thing anyway today and see if the problem still occurs.
thanks

"As per our information, A530 has not been launched with 1x service by Verizon. I may be wrong and would like to get a confirmation from your end. "
OK, I am going by the little 1x icon that appears on the phone.
I will check more into this.
"The issue on Brew 1.1.5.6 and prior handsets on 1x service IS with ISocket connect attempt. Because the previous connection during idle period was torn down by network initiated dormancy, the next connect attempt is not successful. As mentioned previously, on handsets other than T720/T730, it can be solved by releasing the previous socket, creating a new socket and attempting a connection."
OK, but I am doing a release and close myself BEFORE I try the reconnect every time. I do this dozens of times with no problem. But when one fails all subsequent ones fail. Are you talking about Brew's internal socket connection? Meaning the one that stay open during the linger?
"Having said all this, you should rather check if your handsets are actually making 1x data calls. If its not then you should not have to dwell into these issue. Instead, there must be some bug with your app. or your server configuration causing the problem."
I have someone checking on this. Any hints as to how I can find out easily while I am waiting?
This also brings up another issue. How can I tell this at run-time?
My customer will buy their phone and have or not have this service. I want my code to work either way. THis is why I asked if there was any harm in doing the 5 second linger thing as a general practice.
I am going to test with this 5 sec linger thing anyway today and see if the problem still occurs.
thanks

Quote:Originally posted by kurquhar
Are your pings round-trip? IOW, does your server respond or ignore the ping packet? How many bytes long are your ping packets?
The reason I ask these questions is that we have found that TCP "pings" are a very ineffective method for staving off network initiated dormany in (at least) Verizon, for the following reasons:
[=1]
Writing a few bytes to a TCP socket does not guarantee that any IP traffic is generated right away. This is due to Nagle's algorithm, which attempts to minimize the number of small packets in the network (see google).
[*]For some unknown reason, Verizon only uses traffic going towards the phone to reset its dormancy timer - they ignore one way traffic from the phone.
[/=1]
We have had better luck using a second UDP socket to bounce a small packet off of an echo server every 15 seconds or so.
All of my pings are going to the phone from the server. They are very small, but I have not ever had the client ever disconnect during this time so at least that seems to be working.
My problem is when, after all the send and receives are done, and I have closed that socket connection, and some period of time has passed and I need to create a new socket connection, that new connection fails, and all subsequent attempts to create a new socket fail with error 530.
As long as connecting succeeds I have no issues with errors.[/]

Quote:Originally posted by kurquhar
Are your pings round-trip? IOW, does your server respond or ignore the ping packet? How many bytes long are your ping packets?
The reason I ask these questions is that we have found that TCP "pings" are a very ineffective method for staving off network initiated dormany in (at least) Verizon, for the following reasons:
[=1]
Writing a few bytes to a TCP socket does not guarantee that any IP traffic is generated right away. This is due to Nagle's algorithm, which attempts to minimize the number of small packets in the network (see google).
[*]For some unknown reason, Verizon only uses traffic going towards the phone to reset its dormancy timer - they ignore one way traffic from the phone.
[/=1]
We have had better luck using a second UDP socket to bounce a small packet off of an echo server every 15 seconds or so.
All of my pings are going to the phone from the server. They are very small, but I have not ever had the client ever disconnect during this time so at least that seems to be working.
My problem is when, after all the send and receives are done, and I have closed that socket connection, and some period of time has passed and I need to create a new socket connection, that new connection fails, and all subsequent attempts to create a new socket fail with error 530.
As long as connecting succeeds I have no issues with errors.[/]

Quote:Originally posted by zorba
OK, I am going by the little 1x icon that appears on the phone.
I will check more into this.
The 1x icon doesn't help to prove if the service is actually 1x. There is no way through a BREW App. that you can call a function and determine the service option.
OK, but I am doing a release and close myself BEFORE I try the reconnect every time. I do this dozens of times with no problem. But when one fails all subsequent ones fail. Are you talking about Brew's internal socket connection? Meaning the one that stay open during the linger?
No. I did mean the sockets you are using in your app. Since you already release the socket and try to connection again (added I am quite sure your handsets are with IS95 service), the problem may not be due to NI dormancy at all. And thus you should not need the INETMGR_SetLinger(5) workaround.
I would suggest you to test your app. with something like a discard server. So instead of your current server, see if your app can connect to it, disconnect (release socket) and connect again to the server. I feel the problem is to do with your server. If you still face problem even with that server, send in your code to brew-support and we would like to investigate the bug.

Quote:Originally posted by zorba
OK, I am going by the little 1x icon that appears on the phone.
I will check more into this.
The 1x icon doesn't help to prove if the service is actually 1x. There is no way through a BREW App. that you can call a function and determine the service option.
OK, but I am doing a release and close myself BEFORE I try the reconnect every time. I do this dozens of times with no problem. But when one fails all subsequent ones fail. Are you talking about Brew's internal socket connection? Meaning the one that stay open during the linger?
No. I did mean the sockets you are using in your app. Since you already release the socket and try to connection again (added I am quite sure your handsets are with IS95 service), the problem may not be due to NI dormancy at all. And thus you should not need the INETMGR_SetLinger(5) workaround.
I would suggest you to test your app. with something like a discard server. So instead of your current server, see if your app can connect to it, disconnect (release socket) and connect again to the server. I feel the problem is to do with your server. If you still face problem even with that server, send in your code to brew-support and we would like to investigate the bug.

Quote:Originally posted by tamoghna
Quote:Originally posted by zorba
[B]OK, I am going by the little 1x icon that appears on the phone.
I will check more into this.
The 1x icon doesn't help to prove if the service is actually 1x. There is no way through a BREW App. that you can call a function and determine the service option.
OK, but I am doing a release and close myself BEFORE I try the reconnect every time. I do this dozens of times with no problem. But when one fails all subsequent ones fail. Are you talking about Brew's internal socket connection? Meaning the one that stay open during the linger?
No. I did mean the sockets you are using in your app. Since you already release the socket and try to connection again (added I am quite sure your handsets are with IS95 service), the problem may not be due to NI dormancy at all. And thus you should not need the INETMGR_SetLinger(5) workaround.
I would suggest you to test your app. with something like a discard server. So instead of your current server, see if your app can connect to it, disconnect (release socket) and connect again to the server. I feel the problem is to do with your server. If you still face problem even with that server, send in your code to brew-support and we would like to investigate the bug. [/B]
I am still working on this. It looks like there are some issues with how many simultaneous timers I have going at once in Brew,
especially when I am socket connected or just after a socket closure.
I am making an effort to reduce them.
I am also looking into many of the suggestions that people have given here. I will keep you updated....

Quote:Originally posted by tamoghna
Quote:Originally posted by zorba
[B]OK, I am going by the little 1x icon that appears on the phone.
I will check more into this.
The 1x icon doesn't help to prove if the service is actually 1x. There is no way through a BREW App. that you can call a function and determine the service option.
OK, but I am doing a release and close myself BEFORE I try the reconnect every time. I do this dozens of times with no problem. But when one fails all subsequent ones fail. Are you talking about Brew's internal socket connection? Meaning the one that stay open during the linger?
No. I did mean the sockets you are using in your app. Since you already release the socket and try to connection again (added I am quite sure your handsets are with IS95 service), the problem may not be due to NI dormancy at all. And thus you should not need the INETMGR_SetLinger(5) workaround.
I would suggest you to test your app. with something like a discard server. So instead of your current server, see if your app can connect to it, disconnect (release socket) and connect again to the server. I feel the problem is to do with your server. If you still face problem even with that server, send in your code to brew-support and we would like to investigate the bug. [/B]
I am still working on this. It looks like there are some issues with how many simultaneous timers I have going at once in Brew,
especially when I am socket connected or just after a socket closure.
I am making an effort to reduce them.
I am also looking into many of the suggestions that people have given here. I will keep you updated....

Tamoghna,
Could you ask the DDS people to increase the document's revision number (the T720/T720 DDS stayed at Revision E when this note was added) when they publish updates?
We completely missed this 1x-specific workaround because we were only comparing the Revision number when regularly checking for updates.

Tamoghna,
Could you ask the DDS people to increase the document's revision number (the T720/T720 DDS stayed at Revision E when this note was added) when they publish updates?
We completely missed this 1x-specific workaround because we were only comparing the Revision number when regularly checking for updates.