What is a equivalent for this java code in c#
DatagramPacket dp = new DatagramPacket(output,output.length,pack.getAddress(),pack.getPort());
socket.send(dp);
where pack - DatagramPacket, and socket - DatagramSocket?
System.Net.Sockets.UdpClient provides User Datagram Protocol (UDP) network services.
The UdpClient class provides simple methods for sending and receiving connectionless UDP datagrams in blocking synchronous mode. Because UDP is a connectionless transport protocol, you do not need to establish a remote host connection prior to sending and receiving data. You do, however, have the option of establishing a default remote host in one of the following two ways:
Create an instance of the UdpClient class using the remote host name and port number as parameters.
Create an instance of the UdpClient class and then call the Connect method.
And:
Send(Byte[], Int32) Sends a UDP datagram to a remote host.
Or alternatively:
Send(Byte[], Int32, IPEndPoint) Sends a UDP datagram to the host at the specified remote endpoint.
This last one more closely matches your example code.
Related
I have few questions (and problems) about the tcp client class.
1. What IP should I give to it constructor, mine or the remote host that I want to connect to? because in MSDN I see that the constructor takes a local ip endpoint and I can't understand it.
2. What may be the reason for such statement:
TcpClient client = new TcpClient(ip.Text, port: portNum);
to stop the code from running without throwing an exception?
1. The IP you should give to the constructor
You should give the IP you want to connect, look about the IPAddress class.
2. The reason of the statement
Why did you type port: portNum ?
Just write like what is writed in the official documentation :
//Creates a TCPClient using host name and port.
TcpClient tcpClientB = new TcpClient ("www.contoso.com", 11000);
System.Net.Sockets.TcpClient has four constructors. The two constructors that seem to be the source of confusion are:
TcpClient(IPEndPoint) - binds it to the specified local endpoint.
TcpClient(String, Int32) - connects to the specified port on the specified host.
Constructor #1 is useful if your computer has more than one NIC (e.g. Ethernet and WiFi) and you want to pick which one to use. If you construct your TcpClient instance this way, then you would explicitly call TcpClient.Connect to connect the remote host and port number.
Constructor #2 creates the TcpClient instance (picking a local endpoint automatically) and immediately connects using the supplied remote host and port.
I have 2 instances of the same application, on different machines, that should talk with each other, where no one is a typical server or client.
Both instances of the application has a TcpListener, local port = 8000.
One application instance (call it "A") creates a TcpClient. Now, this client can't have local port = 8000, or the constructor throws the socket exception "Only one usage of each socket address (protocol/network address/port) is normally permitted".
So, I create this first client with a random local port, and run Connect() to connect with the other application instance "B".
"B" accepts the connection using TcpListener.AcceptTcpClient(), which returns a TcpClient that can be used to communicate with "A". Though, this TcpClient has the same IP and Port as the TcpListener!? How is this possible, when I could not use the same port when I created the TcpClient manually on "A"? I actually really would like them to use the same port as the listener, on both machines...
So, how can I create the TcpClient on "A" with same port as the TcpListener?
I think you might not fully understand the address port client server architecture.
TcpListener is listening to any connection on address and port. After connection established you can use the "Socket" to receive and send messages from the client and server both.
example:
0.0.0.1 is machine A.
0.0.0.2 is machine B.
you can put a TcpListener that is listening on port 8000 on machine A. When the TcpClient on machine B will make try to connect machine A on port 8000 the TcpClient on machine B will get a generated (by the OS) port.
and then you will have a connection
0.0.0.1:8000 -> 0.0.0.2:3587(Generated port) - so you dont need to worry for the client listening port.
A TCP Connection has always a server and a client side. The server is listening (waiting) for a connection and the client connects to the server.
When the server gets the connection request, AcceptTcpClient gives you the socket of the server side to communicate with the client. A TCP Connection is always defined with the IP Addresses and Ports of the two sides: serverip:serverport and clientip:clientport.
If you want a really symmetrically System, both instances would have a server and a client that connects to the other server. All data that would then always be sent from client to server over the connection that was established by the client.
For Example:
ClientA connects to ServerB -> ConnectionAB
ClientB connects to ServerA -> ConnectionBA
ApplicationA sends data to ApplicationB over ConnectionAB
ApplicationB sends data to ApplicationA over ConnectionBA
If your goal is to use 2 TCP endpoints to talk to each other, without one of them being an
explicit server always, you probably should run a listener (on port 8000, in your case)
on both machines. Next, let each machine try randomly for the connection -- let each
machine pick a random time (between 0 and T) and then wake up. Whichever machine
wakes up first, will call connect() and establish the connection.
As #nivpenso pointed, the end point doing the connect need not explicitly bind to
a port. The connect() step explicitly assigns a temporary random port to that
end point.
So, if hostA initiates the connection, here are all the endpoints you would see
(you can use netstat to see these connections)
HostA:
-- listener: 8000
-- connection to hostB:port8000, localport:xyz
HostB:
-- listener: 8000
-- connection to hostA:port:xyz, localport:8000
On the other hand, if hostB initiates the connection, here are all the endpoints you
would see:
HostA:
-- listener: 8000
-- connection to hostB:port:xyz', localport:8000
HostB:
-- listener: 8000
-- connection to hostA:port8000, localport:xyz'
In the Internet, BGP uses a similar method to connection 2 TCP peers.
So ideally, I am looking for a way to unite TCP and UDP on the server and manage both these connections under individual client threads. Currently, I am wondering if it is possible to accept a TCP connection and set up UDP communication from that.
Here is my ideal setup:
Client connects on TCP to server via TCPClient.connect()
Server accepts TCP connection via TCPListener
when server accepts TCP connection, it also gets the IPEndpoint from the TCP connection
and uses that to begin UDP communcation with:
serverUDPSocket.BeginReceiveFrom (byteData, 0, 1024,
SocketFlags.None, ref (Endpoint)ThatIPEndpointThatIJustMentioned,
new AsyncCallback(client.receiveUDP),
(Endpoint)ThatIPEndpointThatIJustMentioned);
^so this is where I am running into a little bit of a theoretical issue. From my understanding, the endpoints for TCP and UDP would be formatted differently. How can I resolve this issue? I would like to avoid having the client connect to UDP on a separate thread and then uniting these threads under a single managing class.
EDIT:
Here is the code that I am trying to implement:
//Listening for TCP
TcpClient newclient = listenTCP.AcceptTcpClient(); //Accept the client
Client clientr = new Client(newclient); //Create a new Client class to manage the connection
clientr.actionThread = new Thread(clientr.action); //This thread manages the data flow from the client via the TCP stream
clientr.actionThread.Start(clientr);
EndPoint endPoint = newclient.Client.RemoteEndPoint; //so this is the sketchy part. I am trying to get the endpoint from the TCP connection to set up a UDP "connection". I am unsure about the compatibility as UDP and TCP sockets are different.
UDPSocket.BeginReceiveFrom(new byte[1024],0,1024, SocketFlags.None,ref endPoint, new AsyncCallback(clientr.receiveUDP), null); //the AsyncCallBack is like the manager thread for UDP (same as in TCP)
clients.Add(clientr);
There is no problem in creating two listeners in one application, even if they use different protocol. I suppose you are not asking if you can do it on the same port (there is no point to do it anyway).
However listener is consuming thread so it need different thread if there is gui or some process to do in application (for example calculations meanwhile).
If you want to do everything in one thread you must first receive message from first listener, then setup second one. There is no possibility to setup 2 listeners in one thread at the same time because if you setup first listener it will consome whole thread waiting for message.
This was due to a lack of understanding of UDP on my part from the code level.
I ended up setting up the other method I described where it would accept initial UDP packets individually and then direct the communication (EndPoint + Message) towards a managing client class by comparing IP addresses.
I am doing projects in sockets.usually the server listens in a particular port,and the client has to connect to the port then the send and receives will happen.but we don't specify any port number in the client side,but i am in a situation to use a port in a client side, through this port only the messages will delivered to the server.how to do this?
In my client side they are restricting the ports ,so if want use to a valid free port i have to set it in the client program,instead of OS Choosing it.This is my problem.
Bind the client socket to local address (ip and port number) before connecting to server. Be ready to handle errors e.g. when the port is not available (choose next port, retry).
I guess you're using the System.Net.Sockets namespace?
If so, classes like NetworkStream take the Socket as a constructor parameter:
http://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx
Similarly, the TcpClient takes Port and Server as constructor arguments, Port is the same as socket in this context:
http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.aspx
Finally. you can control the number of this socket in a few ways:
Command Line Parameter
Setting in an Application.Config file
Read it from the Registry
There are a few methods for this type of thing.
How to find out Connected Clients Ip Address. And how we can store that address to an array of datatype IPAddress?
Check the RemoteEndPoint of your socket:
If you are using a connection-oriented
protocol, the RemoteEndPoint property
gets the EndPoint that contains the
remote IP address and port number to
which the Socket is connected. If you
are using a connectionless protocol,
RemoteEndPoint contains the default
remote IP address and port number with
which the Socket will communicate. You
must cast this EndPoint to an
IPEndPoint before retrieving any
information. You can then call the
IPEndPoint.Address method to retrieve
the remote IPAddress, and the
IPEndPoint.Port method to retrieve the
remote port number.
If you use higher level components like TcpListener and TcpClient then you can access the underlying socket and retrieve the remote end point.
If you use other technologies like ASP.Net, WCF or Remoting then you must say so in your post.
To store an IPAddress you retrieve the underlying bytes using IPAddress.GetAddressBytes. You reconstruct the address from the bytes using the byte[] constructor.
Are we in Windows? Do you need to use this information inside an application or a console command could do the trick?
maybe you could try with netstat -na in a shell.