I am supposed to connect to external server using UDP sockets in C#..
I could not understand these 2 lines in server usage notes:
"Use of dedicated sockets is enforced."
and
"If the server looses UDP connectivity with the client, it will ..."
I thought that the UDP socket is connectionless!
So what did "looses connectivity" mean? and how to avoid it?
Does there is a known way to ensure "dedicated sockets"?
Thanks
"Use of dedicated sockets is
enforced."
To me this says, create one unique socket for each connection and use it throughout that connection.
EDIT: Just to expand on this, from the servers point of view.
UDP sockets are not identified by the
remote address, but only by the local
address, although each message has an
associated remote address. (source).
That way the server can distinguish from which client each message came from. Because the remote address is made up of an ip address and port combination, you should use the same socket throughout your communication of the sever. This is because if you don't, it's possible you could get assigned a different port next time you change the underlying socket.
"If the server looses UDP connectivity
with the client, it will ..."
It is possible to loose UPD connectivity e.g. either of the endpoints in the connection is lost, say I go to the server and pull the plug?
EDIT2:
Dan Bryant makes an excellent point in the comments, that links in with what I was saying about.
One thing worth noting is that it's
possible for a call to a UDP socket to
throw a SocketException with
SocketError.ConnectionReset as the
error code. UDP does not have any sort
of session with structured
connect/disconnect, but it does use a
dynamically-assigned remote port to
allow replies, which is a kind of
'connection'.
After 2 hours trying different -may be random solutions:
The server wants you to introduce yourself on a port other than the one you will use to actually send data. "dedicated sockets"
You know which IP and Port you are sending start info on, but you do not know which will be used for actual data transmission..
Solution
1- You will create your socket -with known IPEndpoint, and send on it the 'start message'..
2- Then wait to receive from Any IP...
3- The server will response 'welcome message', stating the Endpoint it will use.(by changing parameter ref remoteEP of Socket.ReceiveFrom())
4- You must then change the port you are sending on = remote Endpoint port + 1 (why? standard way or something?)
5- At last you can send and receive normally using these ports
Related
is it possible to have one socket router that would pass incoming sockets to socket servers?
I need this because I want to have multiple servers for handling sockets but only one port for clients to connect to. so if one of the servers goes down, router would send the socket to other healthy socket servers.
Is this even possible and how? or any other solution for my problem?
Yes this is definitely possible, and is used very widespread.
Basically you need to have one TCP server running on that one port you want clients to connect to. Then you can listen for connections. When a connection is established you can reroute packets to other servers (you choose).
Listen on a port with your main server
Accept connections as they come in.
When a connection is opened, read the data in another thread. Take that data and send it to the other server you want to.
Basically, it is a proxy.
I had an argument with a colleague on the selection.
We have two processes running on the same machine.
=> NamedPipe and UDP are KERNEL OBJECT so as far as i understand this is same overhead.
The advantage of UDP is that if tomorrow we will separate those two processes and they will run on two different computers so I do not have to change anything.
I think that the NamedPipe performance are better since there is no need to use a network card to send the information to the same machine (am I right .. sending localhost will use the network card - right ?)
Can anyone advise us please ??
Thanks
Before Implementation , you can care below points :
Named pipes:
Named pipes provide interprocess communication between a pipe server and one or more pipe clients.
They support message-based communication and allow multiple clients to connect simultaneously to the server process using the same pipe name.
Named pipes also support impersonation, which enables connecting processes to use their own permissions on remote servers.
User Datagram Protocol :
User Datagram Protocol (UDP) is a simple protocol that makes a best effort to deliver data to a remote host.
The UDP protocol is a connectionless protocol, UDP datagrams sent to the remote endpoint are not guaranteed to arrive, nor are they guaranteed to arrive in the same sequence in which they are sent.
Applications that use UDP must be prepared to handle missing, duplicate, and out-of-sequence datagrams.
I'm writing a c# application and I have some forms in which users can insert Ip address and port of TCP Listeners that are in other hosts.
So I would check if there is a tcp listener before to continue with the programm.
I don't want to use connect because I don't want to connect to these servers in the same time in witch I perform the control.
So for example
There is a listener
TcpListener server=new TcpListener(IP,Port);
server.start();
In the client application user insert Ip and port of many listeners that I will put in a list so:
//User insert ip and port
// PERFORM check: is there a listener at this ip and port?
than put in a list of available servers.
You cannot do this in a general way. It is not possible to determine whether there is a server socket listening at the remote endpoint, not on your local machine, without actually trying to connect.
Note that this is a variation on the "file exists?" problem, and has the same general answer: don't do that.
Even if you could confirm the presence of a remote server prior to a connection attempt, it doesn't matter because the server could stop working between the time you check for it, and the time you actually try to connect.
So you have to handle the scenario where you attempt to connect to a server and fail anyway. Finding out in advance doesn't make things easier on you, and it doesn't really help the user very much either.
If you really want to validate the user's input, you can in fact go ahead and connect to the server, and then immediately disconnect (with graceful closure...i.e. call Socket.Shutdown(SocketShutdown.Send) and wait for a 0-byte receive to complete before you actually close/dispose the Socket instance).
But personally, I'd just accept the user's input and then if later it turns out to be invalid, let them know when you actually find out that it is.
I am trying to poll a connection from a client connected to my server.
When you use poll you need to give it a socket connection but on the server's side the socket is bound to it's own IP address and a specific port. Making another socket to connect on the same port but with the client's IP address won't work since you can't have multiple connections on the same socket.
I am just wondering what would be a good way to constantly be checking if a client is still connected to the server and also when it disconnects?
I was thinking some sort of timeout check or something. I just wanted to know if there was any generic or proper way of achieving this.
I have tried Socket.Poll but it does not seem to achieve what I want.
To restate my question, how do you check if a client is connected on the server side using TCP sockets in C#?
socket.Receive will just return 0.
From MSDN
If you are using a connection-oriented Socket, the Receive method will read as much data as is available, up to the size of the buffer. If the remote host shuts down the Socket connection with the Shutdown method, and all available data has been received, the Receive method will complete immediately and return zero bytes.
There is also Connected property in the Socket class if you need.
There are two kinds of sockets: For listening and for connections. If a client has connected you must have an instance of Socket that is associated with that connection.
Use this socket to periodically send data and receive and acknowledgement back. This is the only way to make 100% sure that the connection is still open.
Especially the Connected property cannot be used to detect a lost connection because if the network cable is unplugged neither of the two parties is notified in any way. The property can't be accurate by principle.
What is the best way of reading, changing, and resending UDP communications?
For instance i have a server application that tells a master server it's alive sending a packet over UDP on port 3209. It sends out "I'm alive, my ip is xxx.xxx.xxx.xxx and I have currently 3 clients connected to me." the master server then responds, "Hello xxx.xxx.xxx.xxx i see you there."
Whats the best way of MITM (Man In The Middle) of the server sending its packet to the master server? I would like to be able to change "I'm alive," to something like, "I'm changed," or even "currently 3 clients connected" to "currently 0 clients connected"
When trying to make a new UdpClient to the port the server is on i get a "Only one usage of each socket address (protocol/network address/port) is normally permitted" exception.
you mean packet analysis?
You should do two things:
Discover real protocol of
interserver communication. They are
comunicate over UDP but structure of
the data trasfered is not the
network protocol. You should
discover data structure are
transfered between servers
Decide on wich side you are going to
operate with packets. If you are on
one of the servers sides, you can
write filter driver wich would be
change data before it will be
sending or before it will be
recieving by application. If you are
not in the serber side I dont kwnow
hot to intercept network packets
UDP has no integrated security and is not connection oriented so in this case It will be much easier.
You can forge the source IP in the IP packet (no real problem doing that) and just sniff the UDP packets sent to the real IP server. The main problem here is avoiding the main server to receive the real packets from the real client. For that you'll have to tamper with the routing scheme which is not really easy to do...
I ended up writing a program to listen on the port that the server was sending to. I then resent all the data to the master server with the values changed that i needed. When the master server responded back i then sent that data back to the client application. Nor the server or the client application know there is a server in the middle changing the data.
Thanks for all the replies!