Trying to build an application that will act as client connecting to a remote server on a predefined IP and Port. The server will periodically send messages and also forward messages from other clients. I want to be able to receive all oncoming messages without interrupting the connection or state to send data to the server.
My current implementation uses sockets on which I switch between receiving and sending messages every 30 seconds.
This can mean I might miss messages during the time I am sending.
Related
I am trying to make a c# socket application which involves listening to a certain port and take any message sent to this port.
The problem is, I want to make it in a non-binding way. I mean, when I use TCPListener and accept socket,once a connection came, a socket for this connection returns and it deal ONLY with this connection.
What I want is different, I want any connection ( from any remote socket ) to send and I get their messages without being tied with any of them
What I am doing is 2 background workers, one for sending and other for receiving (i.e they are on different ports ). the app will send through the sending some commands depends on the pre-defined message format got on the receiving.
I hope it was clear enough
I have a UDP server in C on a Linux VM and a UDP client in C# in the host Windows 7 machine.
The UDP server listens for connections. UDP client connects then sends a request. The server receives the request, processes it, then sends back a reply (of less than 100 bytes). The UDP client receives the reply and does some work. This process repeats over and over again, at the rate of about 10 request/reply pairs per second continuously.
Currently, I have the UDP server listening and receiving on port 11000 and sending on port 10001, and the client listening and receiving on port 10001 and sending on port 11000. The socket that is being used to listen is kept open on both sides. With sending, each side is opening the send socket, sending data, then closing until the next request is received. So far, this is working.
I understand that it should be possible to use the SAME socket for both sending and receiving. I haven't been able to get this to work yet, but that isn't my question. My question is, is there an appreciable advantage, in my situation, to using the same socket, if it's working as it currently stands? Is there any disadvantage? Or any advantage to having two separate sockets as in my current implementation?
Thank you.
Of course there are penalties doing what you are doing, resource wasting.
Each time you create a socket, send the data and destroy it you are allocating/deallocating resources unnecesarily.
Supose you have a high message rate, each time you send a message you create/destroy one socket, and sockets are not destroyed immediately (at least in TCP, maybe in UDP i'm wrong).
If you can use just one socket, do it, when you are talking to someone with your cell phone you don't buy a new one each time you want to say something in a conversation and throw it to the trash, true? ;)
I am developing a game in Flex.
There are both AIR and Web versions of this game.
AIR app would connect to a server using a UDP socket on a port.
The purpose of the Web version is to allow users to play when they are at work, or on a computer behind some firewall/proxy that blocks some ports. So the web would connect to a server using http connection on port 80.
The server code answering the http connections would be a java servlet that uses BlazeDS.
But if any of you find it more easier to explain for a C# server code(webservices or whatever), it would be ok .
The server code answering the UDP requests would be a simple class listening for socket connections.
My problem is I don't know how to put UDP and http code together. If there are 5 AIR clients, and 5 Web clients, they all need to meet in the server in some common collection variable, so that I can update all clients with latest info.
Who is going to instantiate the class that listens for sockets? And when?
So to summarize:
1. Do I need a dedicated server to achieve what I want?
2. Who will instantiate the udp handling class and when?
3. Is it even possible to keep the udp handling class and the servlet for http connections together? If there would not be http, I wouldn't even need tomcat. But http and udp code need to stay together, so that I can update the players collection. Is it possible to instantiate the UDP handling class and tell it to listen for socket when the servlet is deployed on the server...or something like that?
Any advices are more then welcome.
Thanks in advance,
Miha
http and udp code need to stay together
No they don't. They are transport mechanisms for your game data, so they should be transparent. Your UDP and HTTP servers should connect to your game backend, in what way is up to you. It can be in-memory, by using HTTP and UDP (socket) modules directly from your backend code, or it could be using some sort of service (so you can let other channels talk to the same backend).
This game backend does not connect directly to the user but only talks to the UDP and HTTP modules.
Then from this backend you process messages you receive from both HTTP and UDP, and sends the response over the same channel.
Example:
AIR-client 1 sends a valid login message to UDP server.
UDP server forwards the login message to the game backend.
Game backend returns succesful result message to UDP server
UDP server forwards the result message to AIR-client 1.
Example 2:
Now HTTP-client 1, which happens to be already logged in, requests all users currently logged in. It does so over HTTP, to the HTTP server.
HTTP server forwards this request to the game backend.
Game backend returns information to HTTP server
HTTP server returns response to client.
I'm building a UDP server that handles each incoming request in a separate
thread. The problem is, a UDP client may send out multiple requests
concurrently by using multiple threads. Each thread on the client will wait
for responses from the server. Since UDP is connectionless, a client thread
may receive a mismatching datagram. In this case, does have any
built-in mechanism or pattern that helps a client thread to get the matching response?
(for example send each request from server to specific udp port !!?)
I don't want use queue because it lost concurrently property.
If not, I guess we can build a queue that dispatches responses to
appropriate client threads. However, what if I need to run multiple clients
in different JVMs on the same client machine, and each client will make
requests to the same server?
Use a separate socket for each udp client. That way you have a different ip and port for sending and would receive response on the same i.e. the client which sent the request would only receive it's response (i presume that is what you meant by matching) This should be done automatically unless you share the same socket between threads and use it to send messages to server which seems like a bad idea.
You can set any port in your source (sender port) in client before sending message to server. The server can extract your source port and respond to the same port
e.g.
Client 1 source port:10401 -> server:listening port:2000. Server responds to port 10401.
Client 2 source port:10402 -> server: listening port: 2000. Server responds to port 10402.
If you are wanting to do concurrent connections, make multiple connections. Spawn a new UDP connection on the client, the server will just open a new connection on it's end. Anything sent on connection1 on the client comes in on comes on on connection1 on the server, anything sent on connection2 gets received on connection 2.
I have a custom TCP Server listening on port 5888(dummy port). The proxy server listens for incoming connections. When the proxy receives HTTP request for certain pages, it should relay it to the main server on port 80.For other page requests the proxy is required to send data to the main Server on port 8081.
The port 80 is used to service the HTML Pages where as the port 8081 is used for streaming data to the clients.
I am able to receive the incoming connections on the proxy and then read the data from the clients. After reading the data, I can determine which port to connect to on the main server for sending the data.
I am stuck at deciding how to connect on 2 ports for sending the data from the clients to the Main Server?
In that case you either need 2 socket connection objects to the same IP on the different ports (this is legal), or you have one connection object which reconnects according to the port you have to deal with.
Depending on how often you have to switch connections the latter version might have a huge overhead, plus the first one allows you to send data to both ports virtually simultaneously.
You need to stop thinking of your program as a server. After you have received the connection, read the data, and decided what port to send it to, shift gears and start operating as a client would.
Just open a new connection to "localhost" on either port 80 or 8081 and re-send the data you received as if you were the original client.
Your client is connected to the proxy server on port 5888 so no matter from what real server (Web or streaming) you take the data, you are going to provide the data to the client using port 5888 only.
It seems to be a not so practical solution. I am assuming here that you are trying to achieve a kind of control port and data port structure where one port is controlling the streaming from another port.
Just creating two sockets is sufficient for obtaining data from two servers. Here you will have to manually create a protocol which your client understands as you are going to provide both html and streaming data to the client using single port.