Please excuse the backwards architecture on this one and assume there's not a better way...
I have a Windows Service running on localhost, it listens on TCP port 5432 and broadcasts events to any connected sockets.
Is it possible for a Silverlight 4 in-browser app to connect to this service (thereby receiving these events)? Or are there security restrictions around Silverlight sockets preventing localhost access?
Yes - that is possible though not easy because of security reasons... please see the following links:
http://msdn.microsoft.com/en-us/library/cc645032%28v=vs.95%29.aspx
http://msdn.microsoft.com/en-us/library/cc296248%28v=vs.95%29.aspx
Related
i'm writing a server side application and a windows service which need to be installed on a remote host
the service returns CPU usage to the serverside application - this is NOT the problem
the serverside application deploys the service on the remote host. - also, not the problem
THE PROBLEM:
but how do i setup a socket connection between the two, when i dont want to hardcode the ip address? (for scalability) - do i need to use multicast or is there some devious way of doing this? is there another solution than using sockets? -
i'm new to writing Windows Services.
I need help figuring out how to communicate between the server and the service without hardcoding IP-addr.
thank you in advance.
MY SOLUTION:
I created a windows service, that reads a xml file with the IP and port of the Server application. so when i deploy my client application, i also create a xml file with the network information.
Regards Alex
A lot of communication platforms now use network discovery; there's an article on codeproject that goes into detail about using network discovery.
The problem was, I did not know what machine name the server was running on, in fact I wanted this to be flexible, and selectable by the user.
Seems relevant to http://www.codeproject.com/Articles/16113/Retreiving-a-list-of-network-computer-names-using
Have you thought of using WCF?
http://msdn.microsoft.com/en-us/library/ms731082.aspx
Regarding multicast, you can have a WCF server multicast announce it's availability on a network; see http://msdn.microsoft.com/en-us/library/dd456782.aspx
another solution could be to create the service as a console application with arguments (endpoint ip address) and then just deploy it with the arguments on the remote host
I have a C# applications which acts like a client and it can be installed on any system which is directly connected to public internet (through data cards or port forwarding) or they can be behind router also (without port forwarding).
The other application which is developed using java acts like a server application which is on the public internet. Now, my java application wants to push a message to C# application which is behind router. Java application has the clients public and private (192.168.x.x) IP address. Java application is supposed to run 24x7.
So, now there are two options for me:
Whenever c# application starts it will establish a socket connection with java application and this socket connection will remain open till C# application gets closed.
Whenever Java application has something for C# application it will create a socket connection with C# application then it will push the message and then close the connection.
Now, with 1st option there is a problem that there will be lots of unnecessary connection since there can be thousands of client application and it may happen that on some day there will be nothing to push for some clients. and I don't know how to go for 2nd option.
What will be the right way to accomplish this task (option 1 or 2)?
Is UPnP protocol right for 2nd option? What are the open source UPnP libraries which has both the API's (C# and Java). I found one such called ohnet. Will it be a right thing for me? I didn't found a single small example for OhNet to test.
2) is not feasible if you don't have control over network configuration at the client end. It won't in general be possible for the server to make connections to the client if the client is behind any moderately secure firewall / router.
So you will in general have have to go for some variant of 1) where the client creates a connection to the server.
You don't necessarily have to keep the connection open though - it's always possible to get the client to poll the server periodically to check if there are any new updates.
If you want realtime updates to the client from the server then you will still need to keep a connection open. This isn't necessarily a problem if you use Java NIO you should be able to handle tens of thousands of simultaneous incoming connections relatively easily.
Using option 2, will you have to queue messages for your C# client until it connects? That could make your Java application run into out of memory problems if the C# application doesn't connect.
I would definitely use method 2 by adding a static route in the router (port forward). You should - however - ensure that the server behind the router is protected from the rest of your network (DMZ).
UPDATE:
Perhaps I have missed something here (method 1 or 2) :-) - but just to make it absolutely clear: It is always the client that should initiate the connection to the server. And yes, you could allow the client to request the server for updates on a regular basis.
I have to detect if a server is on or off, some people told me to try using the pinging way, and if it's not working I should use TCP connection between me and the server.
Can someone please explain me whats the difference between these, why does the ping way may not work good?
Thank you.
Using TCP would allow you to verify a certain port/service is operating correctly on a host. While ping would just assure that the machine is responding.
A ping also might be blocked by various firewall settings.
It really will depend on your requirements on what your definition of "up" is for your project.
Just responding, or my service hosted on port X is responding when I open communication.
Referring to a question I asked on SuperUser, which is recommended to be ask on SO.
I am developing a console application that sends packet to a remote server on a specific TCP Port (55000). I only have one computer to develop and test on. Is it still possible to debug my program; i.e. when I F5 debug, I send a test packet (from localhost) to localhost which is listening.
Also, I need to open up a port for development. I follow the this instruction to open a port (55000) in Window 7.
But when I netstat, the port 55000 is not even listed (i.e. the Local Address of 0.0.0.0:55000 is not there...). I also tried restarting the computer, but persist the problem.
Yes, of course you can. Just run the server to listen on port 55000, and then connect to localhost on port 55000.
You can use 2 different sites in the IIS with different ports or you can take advanatege of 'hosts' file to assign some naming for those 2 sites
Yes, it is possible. Although keep in mind that TCP ports for request and response must be different. So, if you bind your server to some port (say 2000), then your client must send requests from different port (80 usually).
We have a server application (developed using .Net 1.1, C#) which listen the port 8086 and the client application, before starting will handshake with this server using remoting.
The application is working fine in almost all environments - Windows 2000/2003/2008/XP/Vista.
Now we are facing an issue with Windows 7.
When we are staring the server, it’s opening the port and will be listening to clients, but when try to send a request from a client who is running in other OS, it gives a message that server is not running.
We disabled the proxy, gave the exceptions for proxy but all went in vain. On further analysis we found that the system is having multiple connectivity (LAN, Bluetooth &WIFI).
When we checked the TCP port using netstat –a it showed the Local Address as 0.0.0.0:8086. So we disabled/removed the Bluetooth & WiFi option and tried again then also netstat is showing LocalAddress 0.0.0.0:8086.
How to go ahead in this situation?
Thanks in advance.
Do a network capture using Microsoft Network Monitor or Wireshark to better understand the underlying TCP/IP packets. That can show what's up easily.