I want to connect to server with multiple clients and some clients in the same computer and same IP address. I mean, in my application, in the different forms, user can connect to server and get value from server in the same time. I read more about multi clients but all of them was about multi clients in different computer or different applications. I think, i handle received values from server in client side with a dictionary that save connected clients and every received value set in a queue, and if not run any received value then get a data from queue and etc. but i don't know how can i know this received values is for which request from client.
I try solve this problem around 3 days and i couldn't. Please if you can help me
For sure it's better to specify your Platform, Environment and ... when you have a question about it, Well in general cases there's no different. BTW, I assume it's .Net.
.Net platform
If you do socket programming and you wanna recognize different requests from multiple clients in same Computer/IP the Client.RemoteEndPoint from TcpClient class give you that. Actually, it's consists of IP:Port and It's a key to get you know how it works separately, which in each programming languages with high probability it would be like that because in the same computer each endpoint needs to have same IP but different port. So even in the same computer you would have this as an ID (IP:Port) and can use it as the key within your dictionary.
General cases
In some general ways for each platform or without usages of built-in frameworks you could consider your server like a WebServer (I see It's more complex) but how a WebServer would process each request by itself even if they are 2 different sessions in 2 browsers from 1 computer and 1 port? So you should implement your code in that way. Actually, you should put some extra information on each request and give them some unique pieces of information (ID) on your own. Then you could identify them from each other.
Related
I have a asynchronous TCP project and I can handle multiple connections.
But,for example:
If I have two clients connected how can I communicate with both of them?
Well, obviously you'll need some sort of container to hold the current connections along with an internal identifier (key) that lets you find the connection you want to send something on.
If you have problems with this, please post a more specific question.
I'm sure this has a simple work around, but right now I seem to have the inability to find an elegant solution. I have built an ASync C# server application which accepts multiple clients and handles them well, but to proceed I need to be able to determine which clients are connected to my server (there will be only two clients both of which do different things).
When my program accepts these clients I want the server to know the clients address and an indication which client is which potentially stored in a small list.
So I guess what I'm asking, is there a simple means of when the client has connected, sending a predefined message to the server letting it know what client application goes to which address?
Thanks
There are numerous ways.
One of the easiest is to have a different port for each of the client applications. The other way is in order to "connect" (after TCP Handshake) is to send a message identifying the application before any data is exchanged. The other option would be to add headers to each requests / reply stating the application and storing that.
You are free to send all kind of data over sockets.
To solve this, invent some kind of protocol between client and server.
For instance sending a first message when connecting to identify the client to the server.
From there on continue with the normal conversation between those two.
Server can accept the message and store of show it, or even reject the client when the first message does not contain the agreed information.
The program I am making requires the use of real time cross computer interactions via the internet.
The issue I'm coming across is that while I wish for the clients to connect to a host client rather then going for a client server model there are a lot of problems in terms of getting the host client able to actually host (accept an incoming connection, etc.)
I'm trying to make the process of hosting a session as simple as possible, so that a user with no networking knowledge can accept incoming connections without having to configure their router or any other such thing. I was wondering how I could achieve this?
Sounds like you want to programatically update firewall rules, given the variation in network set ups, it's not possible to have a one size fits all approach. I think you have three choices, the last probably being the better:
1) http://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol
2) http://en.wikipedia.org/wiki/Tunneling_protocol
3) instructions for users to configure their routers (will be needed as a back-up for users who the first two fail for)
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 am currently new to C# and I need to understand simple server-client architecture!
I am currently trying to write a simple server/client program where basically a client can send a variable to a server and the server can send it to another client. Problem is that I am really blind to this as I am still very new to C# although I have some experience with Java (But still not with networking).
My question is:
How many files will i Have to write?
Can anybody be nice enough to provide me with a framework or example for a program like this?
What is a TCP server?
This is intended to be for an online game. One client will roll the dice and the server must show all the other clients that this is the value the first client rolled.
Any help would be greatly appreciated!
Answer to all of your questions: MSDN - Network Programming (.NET 4)
Since you are planning on TCP (because you want state) you need to develop a strategy. You'll get plenty of information about establishing a connection and moving some sort of data back and forth. Google will give you more than you can handle. Without doing all the work, here are a few steps to get you oriented.
1) Connection Registration - When a client comes online and wants to communicate with the server it first needs to say "Hey I'm here and want to role some dice." This initial handshake could be a connection id that is used for a heart beat and/or transactions. The server will use this to identify data and the respective thread if open.
2) Heart Beat - Now that the client has registered with the server the client is responsible for providing a heart beat saying it's still there and still planning to continue work. Typically every 3 - 10 seconds is good.
3) Develop the Request/Response protocol - For "every command" there will be a formal process. This formal process will include the connection id but also a request id. The client will not accept a response unless it receives the corresponding request id. Furthermore, every request will require a success or fail response to identify if it conforms to the API or what not. Within the request will be the command or action to perform. Some people use int's to dispatch a command id then use a switch on the id to call an entry-point method (cmd id = 1 is connect(), cmd id = 2 is rolldice(), etc). You might include additional payload that identifies the result from the command.
In short, 1 is the handshake, 2 is the keep-alive and 3 is passing data back and forth.
Now whether to use socket or WCF, I'd recommend to have a basic understanding of TcpClient programming then run with WCF. You'll be amazed how simple socket programming is but the overhead is a killer. Nothing to be intimidated by. It's a lot of work to coordinate calls, threads and not to mention security. WCF on the other hand does shave some of this overhead off.
I'd check out this question...
How to use socket based client with WCF (net.tcp) service?
1) The number of files will depend on your particular implementation. You can create this architecture as simply as 1 class for the server and 1 class for the client (you can have more than one class in a file). Depending on the complexity and choices you make during the design you could have many files or just a few.
2) A good tutorial for a simple TCP server / client can be found here
3) A TCP server is a process that waits for a connection from a TCP client. TCP stands for Transmission Control Protocol. From Wikipedia: TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer.