I'm developing a Blackberry Application that does quite a bit of networking, using HttpConnections and InputStreams. I've been testing it in an environment where it has access to a BES, but will be demoing it with only wireless.
Some preliminary testing on a Bold 9000 shows that although the web browser of the phone can get onto the internet, my application cannot. My understanding of it is that the BES usually handles most of the logic of networking, and that the Blackberry itself isn't very good at it.
I've seen some references to having to add ";interface=wifi" to the urls I am trying to connect to, but when I do this, progressively downloading a large movie file will hang after a few seconds.
Is there anything else that can be done to get a Blackberry Application to work with just wireless? Are there signed classes I could use that could handle this?
Edit
It looks like what is going on is that there is a rare chance of the networking just not working -- General Socket Exception. The problem is that for large files, I'm doing many connections, in chunks of 256k, so for large files there's more of a problem of it erroring eventually. I'm really not sure how to handle this.
Edit
I've used a work around with my Connector.open method, using the version of .open that has a timeout option. If a particular networking call doesn't ever return, which was my problem, in addition to the Exceptions, then it retries after a few seconds. It does this for the exceptions as well. This is, at best, a temporary fix, and if anyone knows of a way to improve non BES networking performance, I'd love to hear it.
A simple solution would be to check for the WiFi Coverage Status
public boolean GetWiFiCoverageStatus() {
if((WLANInfo.getWLANState() == WLANInfo.WLAN_STATE_CONNECTED) &&
RadioInfo.areWAFsSupported(RadioInfo.WAF_WLAN)) {
// this.connectionString += ";interface=wifi";
return true;
} else return false;
}
This would ensure that a connection is build only if the device is connected to an Access Point.
Edit:
Second thing you should check is this Knowledge Base Entry (HTTP 413 Request Entity Too Large)
Third addition: Did you use ;deviceside=true in your connection string? without a MDS backend you have to use this appendix to ensure a normal TCP/IP connection
Related
I am wondering if there is a good way of making automated system testing for a Chromecast receiver application?
If you open the application URL in a Chrome browser, the cast_receiver library cannot find the websocket connection on:
ws://localhost:8008/v2/ipc
Since this handles the communication between the app and the Chromecast hardware, I am thinking of something like a Node.js websocket server that can talk to the chromecast receiver app. Is there such a system, or do anyone know if there are plans of google releasing something for this kind of testing?
Also, would there be other problems related to the difference between the chromecast browser and chrome browser? As I understand, the chromecast browser is just a subset of chrome, which makes me think it should work.
No, there is no easy way to do this.
DISCLAIMER: I haven't tried any of what I'm about to suggest. It's also probably a terribly idea as Google could change the protocol any time and in any fashion they desire since it isn't a public thing.
BIG DISCLAIMER: You may be in violation of the ToS by doing this as Section 3.2 (Developer Policies) states that you "may not ... develop a standalone technology ... any functionality of any Google Cast Receiver". Possibly, you'd be making a standalone piece of technology that replicated the IPC functionality. But I don't know. I'm not a lawyer.
If you want to go and do this, I'd suggest making a copy of the Google Cast Receiver SDK (www.gstatic.com/cast/sdk/libs/receiver/2.0.0/cast_receiver.js as of April 28, 2015) and altering it so that it logs out the messages that are being sent and received.
Luckily, it appears that we have logging messages to help us find the relevant code.
The receiving method has the string "Received message". I would guess that "a.message" is what is being received.
The sending method has the string "IPC message sent". I would guess that "a" is what is being sent.
Once you've instrumented your copy of the code, you need to publish it somewhere that your receiver app can see it and then you need to edit your receiver app to point to your new and improved SDK. Please please please make sure that you do this on a non-published app for testing purposes only.
Once that is done, you need to find some way to get your messages out of the code and into something that you can access. You have a few options.
Fiddle around with the code more and figure out how to get the Chromecast to log out the data you want;
Store the information in an array and read it using the debugger;
Open your own socket (or websocket) and send that data to a server that you control.
From here, you can run your app, interact with it, and then have a complete record of the IPC messages that were sent and received. Armed with this, you can create your own Fake-IPC server that listens for specific messages and spits out the stuff that is in your log.
I have a Windows Server 2008 R2 machine running IIS7.5. This webserver hosts many websites under different domains and each website contains several asp.net applications.
Support and development access to this machine is quite restricted due to customer requirements. I want to use the Microsoft.Web.Administration library to query the configuration of each of these applications in an asmx web method:
[WebMethod(MessageName = "GetDatabases")]
public List<Connection> GetDatabases()
{
List<Connection> connections = new List<Connection>();
ServerManager sm = new ServerManager();
foreach (Site site in sm.Sites)
{
foreach (Application app in site.Applications)
{
System.Configuration.Configuration config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(app.Path);
foreach (ConnectionStringSettings cs in config.ConnectionStrings.ConnectionStrings)
{
try
{
SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs.ConnectionString);
connections.Add(new Connection { Site = site.Name, Path = app.Path, Name = cs.Name, InitialCatalog = builder.InitialCatalog, DataSource = builder.DataSource });
}
catch
{
connections.Add(new Connection { Site = site.Name, Path = app.Path, Name = cs.Name});
}
}
}
}
return connections;
}
This code runs fine in Visual Studio but once deployed to the server an error occurs:
Server was unable to process request. ---> Filename: redirection.config
Error: Cannot read configuration file due to insufficient permissions
I researched how to work around this issue and found this page:
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
So I created a new application pool just for this webservice and configured the Application Pool identity to have read-only access to the folder containing redirection.config (C:\Windows\System32\inetsrv\config) using the ACL of the folder. (I did this for the folder rather than the file as it seems that more than one file in the folder is required.)
My question therefore is: as long as I restrict access to the webservice properly, are there any security implications with doing this? It seems ok to me but the implications of making the configuration of these customer sites public could be career limiting to say the least!
Thanks,
Owen
EDIT: Just wondering if I have worded this question properly? So far no-one has taken a stab at answering it so this edit is mainly to bump it ;)
I'm no security expert (so take my words with a pinch of salt), but I would say that there isn't a hard and fast answer on this. However, most probably lean more towards recommending against this.
If your requirement is to allow support to see the connections your different sites use, then I see no issue creating a service like this in general principle, so long as you are careful.
That said, there are a number of things you should think long and hard about before going ahead with it:
Could the same be achieved by simply creating a secured share on the Server, and granting your support/devs RO access to that location? That may be more secure than writing your own service.
If you are doing this via a webservice, you should add security to the service to prevent unauthorised access (I'd probably use windows authentication myself, but that depends on your requirements)
I would recommend that you ensure that this service is not visible outside your Local network: you don't want someone from the wider web to be able to get onto this
Use an SSL connection for your service, to prevent packet sniffers being able to snoop on your traffic and retrieve this sensitive information.
I would recommend stripping out sensitive information from the Connection string before displaying it. At a minimum, I would remove the password. Anyone who needs the password already knows it, or knows how to get it. Anyone who doesn't need it won't be able to get it via this tool. You may also want to strip out all but the last part of the IP, it's not really secure, but it helps obfuscate information that would make it easier to hack.
Above all, you almost certainly want to communicate this to management/the customer, clearly lay out the potential risks, and detail what (if anything) you will do to mitigate it. If they sign off on it after all that, then the responsibility is really with them.
Security of the web service should be your last concern, primary concern is should you even make such a sensitive/confidential data available through a web service?
And the answer is straight NO.
More than security threats there may be quite a few legal implications on doing such a thing. Even if your customer is the sole owner of all the Apps running on their server they themselves may not be free decide about implementing such a functionality, as it may potentially be a threat to sensitive data belonging to their clients. So if you yourself are planning to make such a decision then you can very well imagine the consequences.
Moreover access to the servers and sensitive data like connection strings is restricted for obvious reasons, and that restriction should not be breached under any circumstances.
I have an ASP.NET web page that connects to a number of databases and uses a number of files. I am not clear what happens if the end user closes the web page before it was finished loading i.e. does the ASP.NET life cycle end or will the server still try to generate the page and return it to the client? I have reasonable knowledge of the life cycle but I cannot find any documentation on this.
I am trying to locate a potential memory leak. I am trying to establish whether all of the code will run i.e. whether the connection will be disposed etc.
The code would still run. There is a property IsClientConnected on the HttpRequest object that can indicate whether the client is still connected if you are doing operations like streaming output in a loop.
Once the request to the page is generated, it will go through to the unload on the life cycle. It has no idea the client isn't there until it sends the information on the unload.
A unique aspect of this is the Dynamic Compilation portion. You can read up on it here: http://msdn.microsoft.com/en-us/library/ms366723
For more information the the ASP.NET Life Cycle, look here:
http://msdn.microsoft.com/en-us/library/ms178472.aspx#general_page_lifecycle_stages
So basically, a page is requested, ASP.NET uses the Dynamic Compilation to basically create the page, and then it attempts to send the page to the client. All code will be run in that you have specified in the code, no matter if the client is there or not to receive it.
This is a very simplified answer, but that is the basics. Your code is compiled, the request generates the response, then the response is sent. It isn't sent in pieces unless you explicitly tell it to.
Edit: Thanks to Chris Lively for the recommendation on changing the wording.
You mention tracking down a potential memory leak and the word "connection". I'm going to guess you mean a database connection.
You should ALWAYS wrap all of your connections and commands in using clauses. This will guarantee the connection/command is properly disposed of regardless of if an error occurs, client disconnects, etc.
There are plenty of examples here, but it boils down to something like:
using (SqlConnection conn = new SqlConnection(connStr)) {
using (SqlCommand cmd = new SqlCommand(conn)) {
// do something here.
}
}
If, for some reason, your code doesn't allow you to do it this way then I'd suggest the next thing you do is restructure it as you've done it wrong. A common problem is that some people will create a connection object at the top of the page execution then re-use that for the life of the page. This is guaranteed to lead to problems, including but not limited to: errors with the connection pool, loss of memory, random query issues, complete hosing of the app...
Don't worry about performance with establishing (and discarding) connections at the point you need them in code. Windows uses a connection pool that is lightning fast and will maintain connections for as long as needed even if your app signals that it's done.
Also note: you should use this pattern EVERY TIME you are using an un-managed class. Those always implement IDisposable.
I have a long running ASP response (actually an MVC action) that I want to cancel if the user has navigated away. I think this should be fairly simple:
if(!this.Response.IsClientConnected)
{
Response.End();
}
However I've come across various sources starting that this method is slow.
So I ran my own tests (using MVC mini profiler, though you could use your own):
using (var step = MiniProfiler.Current.Step("Response_IsClientConnected"))
if(!this.Response.IsClientConnected)
{
Response.End();
}
That found that every time I call it it's consistently very fast: under 1ms on my developer set up. This is whether it's true or false.
Under what circumstances is Response.IsClientConnected expected to be slow?
I have to support IIS6 - would Response.IsClientConnected be slower on that?
Does anyone know what it's doing under the covers? At a low level I'd expect the TCP/IP stack to know whether the connection is still there, so I'd expect this check to be instant, but does IIS have to do some additional work to check?
Good question but unfortunately don't have the answer, but can provide the following information. Hopefully this can be a starting point to know what's it's doing under the covers.
The Response.IsClientConnected is checking this by asking the current worker HttpWorkerRequest handling the request.
The worker request can be one of the following types and is created by the ISAPIWorkerRequest.CreateWorkerRequest(IntPtr ecb, bool useOOP) which is called by the ISAPIRuntime.ProcessRequest(IntPtr ecb, int iWRType). This is the entry point from the low level ISAPI to the ASP.NET runtime.
ISAPIWorkerRequestInProcForIIS6
ISAPIWorkerRequestInProcForIIS7 >= IIS7
ISAPIWorkerRequestInProc < IIS6
ISAPIWorkerRequestOutOfProc For out of proc requests
For all the InProc HttpWorkerRequest workers this call is then directed back to unmanaged code by calling int EcbIsClientConnected(IntPtr pECB) which is located in the webengine.dll pECB being the Extension Control Block (ECB), provides all the low level access to the ISAPI request. This reference is initially passed to the ISAPIRuntime.ProcessRequest.
Now I can't find any implementation details of the EcbIsClientConnected method. So without this it's impossible to know what it's doing under the covers and how this maybe differs for the different versions of IIS. Maybe someone else can explain this? I would like to know as well.
We have a DLL used as the middle layer between our website front end and our back end ticketing system. The method of insertion into the ticketing system is a bit complicated to explain, but the short version is that it's slow. The best case scenario I've gotten is a 9 second submission time.
The real problem though, is that I can only get that time through a Windows app, not through an ASP.NET web site. I've set up both a Windows test application and a web page for testing, and even though the code is copied between them the web page is consistently submitting in 17-20 seconds, while the windows app is getting 8-11 seconds.
What could be causing that?
EDIT: In response to a couple of the answers...
The call to the web service is taking the bulk of the time, but I have no control over this web service as it's provided by the ticketing system vendor. I need to find out why the web service is taking different amounts of time when it's being called form a different kind of application. The code is exactly the same in both cases, and it's running a loop then reporting the times recorded.
The code is:
for (int i = 0; i < numIterations; i++)
{
startTimes[i] = DateTime.Now;
try
{
cvNum = Clearview.Submit(req, DateTime.Now, DateTime.Now, false);
}
catch (Exception ex)
{
exceptionCount++;
lblResult.Text += #"<br />Exception Caught: " + ex.Message + #"<br />";
}
endTimes[i] = DateTime.Now;
}
It's the same loop in both cases, and I'm marking the time right before and after the call to the library, which does further processing and then calls the web service. But that processing should be consistent shouldn't it? I have traced during debugging and not seen any delay getting to the actual web service call...
EDIT Again: Working with Ants, in both cases 99.4% of the time is being sent just on the web service call. There appears to be no difference there... except that when timed out the web page is taking longer than the windows app.
Potentially the location of the web service in relation to the web server could be having an issue. Also, the page structure and other processing inside your web UI could be having an impact on how long it takes the application to process.
As mentioned logging items on both sides is a great idea, if that doesn't get you what you need, you might try a performance profiler such as Ants Profiler by Red Gate that can help identify the line, method, or class that is using the bulk of the time.
Are you running both on the same machine? Is the middle-layer that you are calling located on a remote machine? The time durations you mentioned vaguely feels like a DNS timeout issue, when opening a connection incurs the penalty for the first (down/misaddressed) DNS response to timeout. Are you sure that whatever config file/var pointing the DLL to the middle-layer are the same in both invocations?
I second the suggestion to use Wireshark to see what is going on. You can at least satisfy yourself that the backend processing time is (should be, anyways) the same...
Pepper your application on both sides with logs - that will show you where the time is going. If that doesn't help, use Wireshark to trace the network activity.