When I send data using socket in C# on LAN, everything works fine, but how do I send my data over the internet. How to send while the sever I create uses the ip from my compute (private ip)
Can someone suggest on how can I achieve this, basically I should be able to send data anywhere over the internet, not just on LAN.
These days most computers have a router with a firewall between them. Routers, via secreuity design, stop direct access to the computers behind them and their local network.
Yes you will either have to
configure the router to map through a specific port to one of your computers.
Or, the more common way to do this is using a central hub, ie a Web service as an intermediary. This way no firewall are needed as both computers are only connecting one way (out). You could use a wcf service or Web api or many technologies to achieve this and usually you'd use a database to store you game state which makes it persistent
Related
I want to create a simple messaging app that uses tcp protocol to communicate, including with multiple people. Messages get sent to the server, which distributes them to all other clients. At the moment, I have it fully functioning and it works perfectly - on a local computer and a local network, using the ipv4 address.
After an extensive Google search, I discovered that to communicate from a different network I need to port-forward my server. However, how do I make my server able to communicate with clients without all the clients port-forwarding? As far as I'm aware, not everybody's device is port-forwarded.
So, how do I implement this? Is it possible with just C#? Or did I misunderstand something, and port-forwarding isn't really required?
Thanks for all the help.
Why don't you use SignalR. I think it will be best for your problem.
Please actually read my post before placing it on hold!!
Let me start by saying I've been searching for a solution all afternoon and so far I have seen plenty of examples for WCF but none that would do what I need.
I have developed an application in c# that will be installed on customer servers and accesses a sql server on the customer's local network. The application also has the ability to control network relays on the customer's local network and records the status of these in sql. I am trying to figure out a way to have the customer's server establish a connection to our datacenter and be able to issue commands back to the customer's server (retrieve datasets from sql, control the network relays, etc). I have found plenty of ways to have a client call classes on a server but have so far been unsuccessful in finding the reverse. One consideration was writing a web service as part of the application on the customer's server but need a way to establish this connection for customers with dynamic IP addresses and without having to publish through firewalls, etc.
Have you considered using
VPN - Virtual private network
or
Configuring a Port Forwarding redirect on the ADSL modem, and using a solution like www.noip.com ?
If I understand correctly you want to get information from the customer's database, which is behind a firewall and has no known static ip, in addition there might be several hundred customers so a dedicated VPN to the customer is not viable.
First of all: you should not contact the customer database directly. Databases are not designed for this scenario and would probably be left open to attack if exposed directly to the internet.
So you need a service on top of the database. There are two main options you can use for this service:
Polling service
The service is actually a client calling some web service on your network and asking for instructions.
Benefits: easy to implement and deploy.
Downsides: With polling there is always the cost-benefit of scalability/bandwidth use vs. speed of service. There are also some considerations in selecting the time to poll to prevent all the client polling at the same time.
The service is a tcp-server
This can be a usual web service (or RESTfull service) or some other service. The only difference is that it needs to advertise itself. For that you need to have a known directory server. When the service starts it then connects to the directory service and tells it the port it can be contacted on (the directory knows the ip from the connection). It will then need to periodically contact the directory to let it know it is still alive and so any change in IP is detected.
A client on your network would now query the directory to find the address of the client and connect directly to it to issue commands.
Benefit: Scalable and bandwidth efficient.
Downside: More difficult to implement. Requires firewall traversal solutions (UPNP or firewall exceptions).
I'm having trouble really assessing whether or not I'm exposing our internal servers in a very unsecure and obvious way.
I have 2 domains, one internal and one external (dmz) on the firewall. I need information from the internal, and we don't want to start a migration thing, or open up ports directly to the internal server. I'm unable to connect from DMZ to internal, but the other way works fine.
I created a web api service on the dmz, which has a static TcpListener, and accepts only one connection.
I then created a simple console application on the internal server, connecting to this web api TcpListener. It holds on to the connection, and I'm able to send commands via rest-api calls to the dmz server, and send back Json data from the internal server, thus obtaining the bilateral connection I needed.
What I'm wondering is, whether this will pose a serious threat to our security? I don't know enough about network security to be able to say, but the TcpListener only has that one connection, and it's only open long enough for me to occupy this connection.
Can anyone give me a clue as to how (in)secure this solution is?
The server is in DMZ, so anyone can connect to your TcpListener. A port scan will reveal this listening socket. You need to apply authentication (client certificate / IP whitelist / basic / digest / ...).
I am developing a LAN-based database application. It involves a central "server" app to house the database, along with many "client" applications that access it.
The "server" will be a simple C#-based HTTP server that responds to GET and POST requests. However, since it is designed to be able to run from any laptop on the network, I am wondering how to establish the connection between clients and the server without knowing the IP address.
I suppose I could ping every IP address from 192.168.0.0 to 192.168.0.255, and then test those that responded to see if any are my server. But I would only do that if there is no better way. Any suggestions?
Many of these types of discovery services run by putting out some kind of beacon on either the subnet broadcast address (for 192.168.0.0/24 it would be 192.168.0.255) or by putting out a beacon on a multicast address.
Multicast is particularly interesting because in a properly configured network, it allows hosts to find the service even across subnets. Routers and switches won't generally forward broadcast packets across subnet boundaries, but multicast packets will.
The beacon would have information in it such as the port the service is running on, what type of service it is, whatever is needed to start using the service.
To head you in the right direction, what you should do is have the database server running on a specified port. Then send out a broadcast to that port from the client (the system needing to connect to the database). When the database server receives this, it will be able to respond to the sender, allowing a handshake to occur.
Of course, you will need to validate the database server's authenticity (to make it secure, unless you aren't worried about that). This can be as simple as having the client display 4 numbers which then need to be typed into the database, so that the database can send the 4 numbers back to the client proving it is the right computer (how the iTunes remote works), or you can use certificates (but that is too complex a topic for me to cover correctly).
After that the two computers will know each others IPs, and you're set!
I want to create a client/server web application. The client and server can exchange data back and forth. When i say data i mean like a number, for example (0,8,7...), so everytime a client presses a button it sends a number to the server and the server send an acknowledgement back to client. The cleint side i want to put it on the internet so you can access the server from a browser.
Is silverlight socket the way to go? I know theres port restrictions but im planning on using my personal router to open up the ports. Or is socket only for local connections???
Assuming you just have no idea where to start, I'd say you should start by learning about WCF (Windows Communication Foundation). Obviously, start with the beginner's guide. There are some nice introductory videos there that should get you going.
If there is such a thing as Silverlight sockets, you can use them. I'd rather use WCF. Sockets aren't restricted to local connections, but you should be aware that using ports different from 80 in Web applications can restrict some user from accessing your them.
I would like to add that sockets aren't the fastest local connections, but are the base of almost all inter-machine communication.