I'd like to turn off GPRS connection when I close my aplication.
I looked for other problems but:
Power On/Off GPRS on windows mobile
When I use OpenNetCF and set radio.RadioState = RadioState.Off; for PhoneRadio I disable all phone module (I could turn off and on but after that user have to type PIN again)
Other solution:
Closing GPRS Connections On Windows Mobile
recommend to use RAS which is deprecated in WinMo and there is no good documentation.
Is there any posibility to turn off GPRS connection in other way (and if its;s possible using managed C# not P/Invoke and winAPI)?
Your application is not responsible for closing the connection, just as it's not responsible for opening it. Under WinMo, the piece that is responsible for connection is the Connection Manager (CM) and, generally speaking, all requests for connection actions goes through it. For example, when you open something like an HttpWebRequest, CM is notified and it opens a connection for you. Closing a connection, is also out of your app's purview. You can tell CM that you no longer require a connection, but CM is looking for all apps, so it's not going to just shut the connection down. It's going to keep it alive for some period in the event it is either in use or might be called by other application.
This is just how it is. You can't end-run around it with one exception. As the answer you link to says, you can use RAS to forcibly close the connection, but it's not something that I'd recommend becasue it can make CM angry and leave things in a indeterminate state.
Related
I have a c# .net4 application that listens on a socket using BeginReceiveFrom and EndRecieveFrom. All works as expected until I put the machine to sleep and then resume.
At that point EndReceieveFrom executes and throws an exception (Cannot access a disposed object). It appears that the socket is disposed when the machine is suspended but I'm not sure how to handle this.
Do I presume that all sockets have been disposed and recreate them all from scratch? I'm having problems tracking down the exact issue as remote debugging also breaks on suspend/resume.
What happens during suspend/resume very much depends on your hardware and networking setup. If your network card is not disabled during suspend, and the suspend is brief, open connections will survive suspend/resume without any problem (open TCP connections can time out on the other end of course).
However, if your network adapter is disabled during the sleep, or it is a USB adapter that gets disabled because it is connected to a disabled hub, or your computer gets a new IP address from DHCP, or your wireless adapter gets reconnected to a different access point, etc., then all current connections are going to be dropped, listening sockets wil no longer be valid, etc.
This is not specific to sleep/resume. Network interfaces can come up and go down at any time, and your code must handle it. You can easily simulate this with a USB network adapter, e.g. yank it out of your computer and your code must handle it.
I've had similar issues with suspend/resume and sockets (under .NET 4 and Windows 8, but I suspect not limited to these).
Specifically, I had a client socket application which only received data. Reading was done via BeginReceive with a call-back. Code in the call-back handled typical failure cases (e.g. remote server closes connection either gracefully or not).
When the client machine went to sleep (and this probably applies to the newer Windows 8 Fast Start mode too which is really just a kind of sleep/hibernate) the server would close the connection after a few seconds. When the client woke up however the async read call-back was not getting called (which I would expect to occur as it should get called when the socket has an error condition/is closed in addition to when there is data). I explicitly added code on a timer to the client to periodically check for this condition and recover, however even here (and using a combination of Poll, Available and Connected to check if the connection was up) the socket on the client side STILL appeared to be connected, so the recovery code never ran. I think if I had tried sending data then I would have received an error, but as I said this was strictly one-way.
The solution I ended up using was to detect the resume from sleep condition and close and re-establish my socket connections when this occurred. There are quite a few ways of detecting resume; in my case I was writing a Windows Service, so I could simply override the ServiceBase.OnPowerEvent method.
I am working on porting a Windows Phone application to Windows 8 Metro, using the WinRT API. It is a networking app that makes use of sockets on arbitrary ports (different servers use different ports) On the Wp7 platform, I am able to set both requirements and preferences on which network connection type to use when opening up a socket connection. For instance, by default the socket will only connect on WiFi and not the cellular data connection to protect the user from unexpected data use, but the user can not only set it to use the cellular connection, but to use it even if they are connected to wifi. This is useful for instance if the user is on a corporate network behind a firewall using a wifi connection, but the server or port they want to connect to is blocked by the corporate firewall. In this case, the user can tell my app to use the cellular data connection even while connected to WiFi, so that the connection can go through.
So far, on WinRT, I have only been able to get information about the currently active internet connection, and to enumerate through each connection. I don't know, however, how to tell a StreamSocket to prefer connecting via an alternate data connection from the currently active one or if this is even possible. Without this capability, the network firewall scenario above will not be possible from the app's end. The user would have to go to system settings and disable wifi just to work with my app. This is not ideal - my users on Windows Phone love the ability to set this preference without turning wifi on or off.
Is there a method of setting a network adapter preference programatically in WinRT the way it can be done in WP7?
Judging from the (preliminary) documentaion, I don't believe it's possible to do this using the standard APIs, without digging deeply into how sockets are instantiated in WinRT - that is, without doing stuff that would get your app disqualified from the Store anyway.
The whole point of the new and redesigned networking APIs is to allows the user (well, and Windows itself) to set the current connectivity options to how the want them, and allow your app to adapt its network usage patterns to the current capabilities of the network.
Arguably, it is a step back from what was available on WP7. But the argument here is to let the system and the user chose what's more correct at this moment, and have apps adapt to that, instead of having the apps to come up with logic for what network interface to use.
I'm developing an application that in the event of losing connectivity restarts the phone.
Before this step we'd like to close any open connections through Connection Manager. I understand we can use ConnMgrReleaseConnection to release a connection but is it possible to get the Connection handle if the connection was established through another application?
If connection manager fails to close the connection we can then perform a RASHangup but we'd like to attempt it through ConnectionManager first.
Nope, there's no way to do it through connection amanger. The handle ConnMgrReleaseConnection wants is the one returned from the call to ConnMgrEstablishConnection. Presumably the "other" application called this and has the handle, but even if that app could give you the handle, it would be invalid in your own process space anyway.
Generally it would be bad form to do something like this anyway, as I'd assume that the app that openened the connection would expect it to always be open once it had asked for it. Forcibly closing it (even through RAS) without that app knowing could lead to unexpected behavior. Probably not a huge issue for you if you're just going to restart the phone, but if you have any sort of control over that other app, I'd add handling where you can tell it to close it's connections.
I'm currently working in C# and I need to check the state of the JMS connection that i made (whether it's connected / disconnected). I'm sure that I can connect and disconnect succesfully..its just that i need to display the status of the connection in my UI.
Is there any properties of the JMS connection that states connection status? Or is there any other method that i can use to check the connection status?
Thanks for your help. :)
Currently, I'm using the ExceptionListener to listen for any exceptions and a flag will be set to false when any exception is catched. And when I'm connecting, I will set the flag to true vice versa when i disconnect, I will set the flag to false.
This flag will be used by my UI to detect whether the connection is up or not.
However I was thinking that if theres any property / methods of the IBM connection which can be used to show the state of the connection as its a much better solution. For SonicMQ, theres .getConnectedState() which shows whether the connection is active or inactive. I was wondering whether if IBM have something similar to SonicMQ?
You can use the Connection.setExceptionListener() method to be notified asynchronously of exceptions detected in the connection. If a problem is detected the onException() method is called.
Be sure to set the FAILIFQUIESCE property on the factories and destinations so that your connection is notified and closed in an orderly fashion when the QMgr is shut down by the administrator.
In v7 of WMQ it is possible so enable session reconnection in the transport. In this case, the application may not be aware that the connection was interrupted but you can treat it as having been continuously connected.
Note that, for the most part, exceptions are driven by the application's API calls. So if the connection is lost, you may not know about it in real time but rather find out when an API call is made. If the application sits idle for long periods of time and you want a real-time display of connection status. Please see also "How to find out if JMS Connection is there?" for more on that topic.
WMQ v7 has options to reconnect the client automatically. You must be using v7 at both the client and the server for this to work. Since v6 is end-of-life as of Sept 2011, it is best if you develop this app on v7. You can download the v7 client as SupportPac MQC7. When JMS client reconnect is enabled, the application may not be aware of the connection activity except as a delay in responding to an API call while the connection is rebuilt. The length of that delay depends on channel tuning set by the administrator and in the connection factory.
I'm developing a compact-framework application for a Windows Mobile device to work with SQLServer Server trough 3G.
The problem is that the device disconnects automatically from 3G after some idle time, and i have reconnect manually, this is not bad at all, the customer doesn't need permanent 3G connection, and it extends the battery life.
But... is there any way to check (in c#) if the 3G connection is running and if not, activate it?
My device is an Intermec CN50.
Thanks and excuse my poor English.
I guess you can use Connection Manager's API to do this. Here is an article of using some API in managed code.
You can check the connection status with ConnMgrQueryDetailedStatus and act based on that information.
OpennetCF already did the wrapping for you, if you are willing to use a free 3rd party assembly. Check out their Connection Manager.