I been trying to learn the TCP protocol. so I am able to transfer data between two computers on the same network as:
\\the server:
var server = new TcpListener(ipAddress, port); //create a server
server.Start(); //start the server
//wait here until a client get's connected to this computer
TcpClient someClient = server.AcceptTcpClient();
NetworkStream stream = someClient.GetStream(); \\create a network stream object in order to read and send data to the other connected computer
once the server is running, the client application will be able to connect to the server as:
//Client:
var client = new TcpClient(serverIP, port);
NetworkStream stream = client.GetStream();
//initialize data to by some byte array. the data you wish to send
stream.Write(data, 0, data.Length);
byte[] bytes = new bytes[1000] //instantiate a byte array
connection.stream.Read(bytes, 0, bytes.Length) // wait here until data is send
// in this line data has been received and it will be placed the bytes array
I label each node with a different letter. for example note how computer A and computer C happen to be on the same network:
Hope this picture helps me explain what I mean.
Establish connection between computer A and C:
If I want to establish a connection between computer A and C then that will probably be the easiest case. In other words I will not have to do any kind of port forwarding in order to establish the connection.
Establish connection between computer A and server S:
if the client computer happens to be computer A and the server computer happens to be computer S then computer A will be able to find server S. So this connection should be simple too.
Establish connection between computer A and computer B: (here is my problem)
So if computer A wants to find computer B then router Y will have to forward all traffic from port 'somePort P' to computer B and A will have to provide the ip address of router Y or the WAN ip address.
Until this point my title question should not make sense let me explain what I mean when I say "Pass tcp connection to different computer"
I actually need to establish a connection between computer A and computer B without having to configure the routers. I been thinking a lot and I think this should be possible: (it's a little crazy though)
if you remember from my previous code once the connection was established, everything that was send/written through the network stream is received by the other end of the connection. so because computer A is not able to connect to computer B then make A connect to the server S. So far there is a connection between computer A and server S. Ok now establish a tcp connection between computer B and server S. by now the server S should have two distinct tcp connections, one to computer A and the other to computer B.
Because the server has two distinct tcp connections it should have also two NetworkStream objects. let's say that the tcp connection between server S and computer A has the object NetworkStream streamA; and the tcp connection with computer B has the object NetworkStream streamB;
So here comes the crazy part. The server S serializes the instantiated and working object streamB and sends that object to computer A. then computer A deserializes that object and cast it to a NetworkStream object. Computer A should now have a copy of object streamB. WHAT WILL HAPPEN IF THEN YOU SEND DATA THROUGH OUT THAT STREAM!? theorically computer B should receive the data I think. I mean maybe I will have to modify each package header information so that router Y treats those packages as if they where coming from Server S!
the reason why I want to do this is because I have created a server application and client application where it will sync files between two computers on a specific folder. a lot of times users using this program do not know how to enable port forwarding. I also know I may be able to solve this using what is called as "tcp puch holing" but I have not been able to find a working method on c#....
The method you have suggested won't work. A and B are both sending traffic to S. No matter what S sends to A or B, A and B will still have their routers (X and Y) passing traffic only to S. What you want is, as you mentioned, NAT hole punching.
The basic idea of NAT hole punching is to have A send traffic to B and B send traffic to A simultaneously. If done correctly, each router (X and Y) will think the packet from the other side is a reply to the packet it sent, and they will establish NAT entries allowing A and B to talk to each other directly. This is almost impossible to do for TCP, but can be done for UDP.
Trying to send streams or connections over connections is akin to trying to send a telephone over a telephone line. It is what philosophers call a category mistake. You can't do it. A stream is an aspect of a socket, and a socket is an endpoint of an existing connection. Period. It can't be sent anywhere.
Related
I'm currently working with TCP/IP Sockets, My client console program has to connect with server which is my PC, If the destination in the client program is specified as a local host it works fine, what I need to get done with is to connecting the client with my server through internet, what I did is looked up for my IP address on http://www.whatismyip.com/ and tried but it didn't work as I think it's a Network Interface IP address, then I altered destination IP address in client program specifically to the address of my computer which I want it to be a server, but that didn't work also. Here's my code.
Ip = (IPAddress.Parse("192.168.1.4"));
MyClient.Connect(Ip,6000);
GetStream = MyClient.GetStream();
Console.WriteLine("CONNECTED TO SERVER");
Read = new BinaryReader(GetStream);
Write = new BinaryWriter(GetStream);
There 2 things (at least) that you should be aware of:
1. To access your computer from Internet (from the public address, the one you get with whatismyip.com) you need to open the port (6000) at the router, and tell the router to what IP it should forward the incoming connection. You could specified specifics ports or put a DMZ host where all the incoming connections will be routed to that host/PC. Read your router manual to see how that is done.
2. You cannot access your public IP from the inner side of the router (intranet), if you want to connect to your public IP you need to be in another network.
If you have a dynamic IP (is the default) every time the router is powered off and on then, most probably, that IP would change, you need to investigate thru whatismyip.com in order to know what IP has been assigned. You could connect to dyndns.org and ask for a host name myhost.mydomain.com (.es, .fr, etc), and in the router tell the DDNS (Dynamic DNS) to update that host every time the IP changes. In your client program you then connect to MyClient.Connect("myhost.mydomain.com", 6000);
Hope I explain myself well enough, anyway, if you have any question let me know.
I'm currently programming a UDP application which allows clients to login. After that, their endpoint gets stored in a list.
private void socket_Callback(IAsyncResult result_)
{
EndPoint remote = new IPEndPoint(IPAddress.Any, 0);
socket.EndReceiveFrom(result_, ref remote);
if (!listOfEndPoints.Contains(remote))
{
// registration process
// add it to list
listOfEndPoints.Add(remote)
}
else
{
// process packet
}
}
However, sometimes a client's NAT will assign every packet a different external end point. If the registration packet's source end point is 12.34.56.78:1000, that end point gets added to the list. If the same client then however sends another packet, the NAT will assign it a different port, so its source end point will be 12.34.56.78:1001.
This results in the server assuming the client is not registered and try to process the packet as a registration one. Needless to say this won't work.
A way of fixing this would be to send an ID (which could however be faked easily, if it's not super-cryptic) to the client. However, the client would have to add it to each packet it sends to the server.
So it wouldn't be very effective to do it like that.
Is there any other way of telling that the packet has come from the same client as the registration packet?
You should definitely not use the source IP address and port of a UDP packet to associate it with a logical connection. You should include the ID of the connection in each packet and update the IP and port you respond to if you receive a new IP and port for the same logical connection. If connection hi-jacking is an issue, you may need to implement some form of security, such as a secure checksum in the datagram.
TCP handles associating packets with connections for you. With UDP, you must associate datagrams with logical sessions yourself. I don't know why you think it "wouldn't be very effective to do it like that".
One of the tradeoffs of UDP is that if you need anything TCP provides, you have to code it yourself.
By the way, I've never seen ports shift in this way. Are you sure the client code isn't broken, perhaps opening a new socket for each datagram it sends.
I write a comunication program with c/s mode in C# ,server and client program on different computer. Today after client progarm connected to server progarm ,then I pulled out cable from network adapter (after this , client and server program didn't do anything), stranger thing happened. I found out socket of server program still keep connected status. and I use command "netstat -a -n" to retrieve network information ,and get information like following :
TCP 192.168.1.2:3645 192.168.1.3:1863 ESTABLISHED
192.168.1.2 (Server IP Address)
192.168.1.3 (Client IP Address)
Do anyone know the reason ? how to solve this problem .
I wanna how server program can receive the event and close the socket when network cable of client computer has been pulled out.
Please give me some advices or solutions.
Thanks
I think it can be solved by using TCP keepalive.
refrencehttp://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
after connecting , set socket keepalive property . msdn say this switch default status is off , if set keepalive to on , socket will check the network status automaticly , and first check time is 2 hours after last operation on socket. but the time can be adjsut to short . then after first check , socket will servral times. if connection is down or died,
socket will throw exception .
C# Source:
uint dummy = 0;
byte[] inOptionValues = new byte[Marshal.SizeOf(dummy) * 3];
//set keepalive on
BitConverter.GetBytes((uint)1).CopyTo(inOptionValues, 0);
//interval time between last operation on socket and first checking. example:5000ms=5s
BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy));
//after first checking, socket will check serval times by 1000ms.
BitConverter.GetBytes((uint)1000).CopyTo(inOptionValues, Marshal.SizeOf(dummy) * 2);
Socket socket = __Client.Client;
socket.IOControl(IOControlCode.KeepAliveValues, inOptionValues, null);
I have checked. It's running ok.
You can't.
The only reliable way to check connected status is to send data over the wire, so: Deal with connection failures during send/receive, and, optionally, periodically check for connection status by some form of ping, if you want connection status during idle periods.
Im a bit unsure but if you try to read data from the socket after you pulled the cable it will tell you that its not connected any more..
Is there any way of dealing with sessions with sockets in C#?
Example of my problem:
I have a server with a socket listening on port 5672.
TcpListener socket = new TcpListener(localAddr, 5672);
socket.Start();
Console.Write("Waiting for a connection... ");
// Perform a blocking call to accept requests.
TcpClient client = socket.AcceptTcpClient();
Console.WriteLine("Connected to client!");
And i have two clients that will send one byte. Client A send 0x1 and client B send 0x2.
From the server side, i read this data like this:
Byte[] bytes = new Byte[256];
String data = null;
NetworkStream stream = client.GetStream();
while ((stream.Read(bytes, 0, bytes.Length)) != 0)
{
byte[] answer = new ...
stream.Write(answer , 0, answer.Length);
}
Then client A sends 0x11.
I need a way to know that this client is the same that sent "0x1" before.
Each TcpClient instance is for a different connection. A connection in TCP consists of four things: source IP, source port, target IP, target port. So, even if you have the same target IP and port, and the same source port, you have two different connections.
Data sent by one client will not be mixed in with data sent by the other client. Data sent by a client on a connection will be received in order over that connection.
The only time that Sessions become an issue is to remember the client after the connection is closed.
You would probably need to implement your own protocol in order to identify the clients. Perhaps define a chunk of bytes, where in addition to the data you also include a client identifier.
You'll need some sort of authentication or pre-negotiated token, and all of this somehow encrypted with some salt.
There is a lot of existing literature on how sessions are implemented in the Web world (HTTP).
One key is whether you are closing the client connections, or are they persistent? If they are persistent, then simply identify them by their object reference. If not, then...
1) You can do simple sessions based on the source IP address. But if multiple clients are behind a NAT firewall, sharing the IP, then that doesn't work, see the next option.
2) Use a "cookie"
3) Use authentication to identify each client
Every option except IP based sessions requires adding something to the protocol itself.
Some things to remember with sockets. The remote IP + remote port uniquely identifies a client TCP socket. Multiple connections from the same remote client will have diffent remote ports. But you cannot rely on that if the socket closes, because the remote OS may recycle the remote port for a new connection once the old one times out.
Context: I'm porting a linux perl app to C#, the server listens on a udp port and maintains multiple concurrent dialogs with remote clients via a single udp socket. During testing, I send out high volumes of packets to the udp server, randomly restarting the clients to observe the server registering the new connections. The problem is this: when I kill a udp client, there may still be data on the server destined for that client. When the server tries to send this data, it gets an icmp "no service available" message back and consequently an exception occurs on the socket.
I cannot reuse this socket, when I try to associate a C# async handler with the socket, it complains about the exception, so I have to close and reopen the udp socket on the server port. Is this the only way around this problem?, surely there's some way of "fixing" the udp socket, as technically, UDP sockets shouldn't be aware of the status of a remote socket?
Any help or pointers would be much appreciated. Thanks.
I think you are right in saying: 'the server should not be aware'. If you send an UDP packet to some IP/port which may or may not be open, there is no way of knowing for the server if it reached it's destination.
The only way for the server to know is to have the client send an ACK back. (Also both the client and server must have resend mechanisms in place in cases of lost packages).
So clearly something else is going on in your code (or with the .Net udp implementation)
EDIT:
After Nikolai's remark I checked the docs. And indeed there is a distinction in .Net to about being 'connected' or 'connectionless' when using UDP.
If you use code like this:
UdpClient udpClient = new UdpClient(11000); //sourceport
try{
udpClient.Connect("www.contoso.com", 11000); //'connect' to destmachine and port
// Sends a message to the host to which you have connected.
Byte[] sendBytes = Encoding.ASCII.GetBytes("Is anybody there?");
udpClient.Send(sendBytes, sendBytes.Length);
then apparently you are 'connected'
However if you use code like this:
UdpClient udpClientB = new UdpClient();
udpClientB.Send(sendBytes, sendBytes.Length, "AlternateHostMachineName", 11000);
then you can send to whomever you choose without 'connecting'.
I'm not sure what your code looks like, but it might be worthwhile to check if you are using the correct set of commands which doesn't assume a 'connection'