We currently have a silverlight application (kind of a game) and we need to add more functionality which requires more interaction with the server.
We currently do all interaction by HTTP requesting data from the server and then processing on the client - works well, until we have a lot of requests or larger data amounts being returned.
Sockets in Silverlight only work on port numbers between 4502 and 4534, is there a way of making this work on the internet? A way of allowing the user to simply accept and open up a port?
What is actually blocking the port range?
========
Just to add, is this somthing that is possible in Java (http://homepages.uel.ac.uk/2795l/pages/socketap.htm)
The only way to achieve this is via a proxy on the server or some sort of port forwarding taking place on the server.
This can not take place on the client side by itself.
What is actually blocking the port range is the SL runtime. It does this for security reasons.
In reality making use of sockets in an Internet based application would provide some hurdles most notably the need for the firewall to allow ports 4502-4534 to be open for Silverlight communication. This is one reason that the use of sockets is used more within an Intranet application where the need to open ports is non-existent (for the most part). Since Silverlight has defined these ports as the means of communication for their runtime it at least gives the admins some control over that range; versus allowing the runtime to operate on any given number of ports.
No direct way around it ( http://blogs.msdn.com/b/ncl/archive/2009/06/23/why-does-silverlight-have-a-restricted-port-range-for-sockets.aspx ).
Related
I'm facing a problem that gives me a quite hard time ...
People having trouble to execute a program that needs specific ports to be open, sadly they don't know if its a clientside problem caused by blocked ports, of it its simply a software problem.
So I thought about making a program that checks if the user can access the provided ports, after I made the WPF application, I was thinking about having an easier access to such functionality and tried to produce a Silverlight Version.
Questions:
a.) Is there even a way to check if the user can connect to specific ports that aren't in the range of 4502 - 4534 within a silverlight application that runs as plugin in the web browser ?
b.) Is there a way to do this, even without having access to the specific server to provide a policy file?
If you trying to do it from the in-browser application that its a no. Trusted silverlight application should be able to connect to any port without restrictions.
Is it possible to make bittorrent client within silverlight, which will run in browser?
this would be unusual bittorrent client, he will download data from the server and will seed it. is it possible to do?
Is it possible to do within different, web tech, such as e.g. JavaFX?
Yes, completely possible. You can't receiving incoming connections, but that's no requirement for Bittorrent. The only thing that makes it difficult is that the peers you are connecting to need to serve a socketpolicy file on port 80 or 943, and almost none of them do. Without this policy, the Siverlight BT client will only work in the trusted 'Out of browser'-mode, which make it less usefull.
It's like a chicken-egg problem: as long as their is no large userbase for a Silverlight BT client, 'normal' nodes will not open port 943, and without that port, there never will be a large userbase for such an client.
Adobe solved this smartly by introducing Cirrus, their hosted rendezvous routing service which makes P2P possible from Flash without torrents.
No. You don't have access to the client's file system outside sandbox access.
http://betaforums.silverlight.net/forums/p/9351/29437.aspx
I currently need to make the silverlight 4 in-browser app that can receive push messages from the server. I presume using sockets is the best way, and will also allow a connection between server and client to transfer data and update the page.
But I am worried about firewalls and/or proxy servers.
Is it possible to have push technology, or even sockets at all, whilst behind a proxy that may block everything that isnt on port 80?
Or is it possible to have socket connections on port 80 which would be perfect because it would bypass both proxy and firewall. I am aware that there is a set range of ports available for silverlight, so im meaning a work around.
While on the subject...Would sending a mass block of data from silverlight be faster through sockets, ASP.NET AJAX, or connection to an ASMX web service?
Thanks a ton!
Here's a great article on WCF Polling Duplex (HTTP Long polling or COMET Style) hopes this helps. It's a bit out dated by the content will get you started.
http://tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html
You can't connect to TCP socket with port 80 in Silverlight. As you've state there is a limited range of ports (4502-4534) you can connect to and thats it.
Yes firewall will be a concern, just as with other applications such as RDP remote access the firewalls involved between the client and server need to allow connection through one of the allowed port numbers.
Speed of data transfer is largely a function of its encoding. (I don't think AJAX is in the picture here). Ultimately sockets with binary encoding tend to be a bit quicker especially for frequent small transmissions. Whereas HTTP suffers with a bit more overhead however you are much less likely to have a problem with a firewall.
Unless you have a really, really good reason to use sockets use a HTTP based protocol instead. If you abstract out this part of your app reasonably well you could always swap it later.
Have you considered using a WCF PollingDuplex Channel? This allows you to create the "push" from server mechanism whilst sticking with HTTP. In addition much of the plumbing is done for you.
I need to detect the presence/absence of internet connection. More precisely, let us suppose that the application is broken up into 2 parts - A and B.
A is responsible for checking whether or not the system is connected to the internet. If it finds that there is no connection, it starts up part B. And as soon as it detects that there is a network connection, it kills B and continues its own work.
What would be the best way to do the A part of the application? Continual pings sounds hideous. There has to be a better way of doing this (preferably in C).
With sufficient privilege you can test the various network interfaces and examine their state. This would tell you if any of the interfaces was connected to a network and operating. However, this won't tell you if the connection is actually usable, i.e., connected to the internet (or your local net if that's all you need). I don't know of anyway to do that short of actually using it.
Using ICMP (ping) can be useful at a low level, but presumably what you need is a connection to an actual endpoint via TCP/IP to do real work. I would say that you should change the design of your application so that B is responsible for indicating when it is unable to continue due to the absence of resources that it relies on -- network or otherwise. A and B should communicate so that A is aware of the situation and is able to either kill B or respond to B terminating itself and thus continuing its work.
A lot of companies have measures in place to prevent outgoing ICMP requests, TCP connections to ports other than 80/443 for example, or even to prevent you from reaching the internet directly by (transparently) proxying your traffic.
Under an internet connection I would understand any way to contact the outside, be it UDP, TCP or ICMP. Depending on what your application needs to contact the internet for, I would suggest to check over the same protocol, as that is the only thing that matters to your app.
If your application uses HTTP to communicate to an external source, try to connect to a few sites you would suspect to not be blacklisted and that have a reliable uptime. Like google.com, microsoft.com, apple.com, and so on...
Edit:
I am unsure what the specifics are, so let me give you an example with a hypothetical situation.
Application A collects data on the system it is running on and forwards it to a Web Service listening on yourserverhost.yourcompany.com:80
Application B would basically take over the job of the Web Service when it is down and log everything so no data is lost.
When all is well, App A will be sending the data to your web service
Once this connection drops, you immediatly launch App B (the obvious remark here would be, why not keep App B running as a failsafe)
App A connects to App B and forwards what it had been buffering
App A continues to try to reestablish the connection to your Web Service and once it is back up will request App B to stop
If the problem you are facing is nothing like this, please provide a more concrete description of what App A and App B are supposed to be doing. I will be more than happy to help.
In your code, you have to check whether the internet connection exists by using a socket to open a connection to a website.
Firstrun: Ask user to input the network parameters, like proxy settings. Save this info.
Next runs: Use these settings to check for the Internet connection. You may simply do a DNS search.
If results are negative, ask user to check settings.
Check whether the cable is connected , if so ping your internet connection to any host as google.com.
ping google.com
Let me explain my scenario before asking the question.
I am in creation phase of 17 different multiplayer games that can be played online, directly from browser.
To accomplish this, I have choosed Silverlight.
Communication will be done using Sockets.
Image 17 different type of games like Chess, Backgammon, Pool and hundred of online users communicating between client app and server app using Sockets binded to the same PORT number.
Wouldn't be faster (for my server) if every different type of game will use another PORT number ? Chess will use 4502, Backgammon will use 4503, Pool 4504.
Will this make a difference ? Or should I use the same PORT number 4502 for all games with no fear that something bad can happen ?
A socket that has been established as a server can accept connection requests from multiple clients. The original server socket does not become part of the connection. The accept method makes a new socket which participates in the connection and returns this socket. The server's original socket remains available for listening for further connection requests.
So it has no advantage to use different server ports. After all web servers get all their requests on port 80 and handle this very well.
As far as speed of processing on your server goes it will most likely make very little difference whether you receive all your communications on one socket or 17. The one socket approach would be a tiny bit faster since your server application will probably have fewer threads to switch between. However there will be other things that will have a higher overhead such as actually processing the game moves or authorising client requests etc.
As for the question of whether to use one or multiple sockets the bigest thing you should think about is deployment constraints. The TCP port numbers that Silverlight is allowed to use a non-standard (i.e not 80 or 443) and if there is a firewall or proxy between your client and server you may be better sticking to a single port to make the access control list on the firewall simpler.