You real problem in that, from the server side, the clients NAT/Firewalls are going to deny all inbound connections anyway. The clients would have to open a well-known port on their end (firewall) to let other clients connect to them.
The internet side of the NAT would open a single, well-known, port and forward that port to a well-known port your app is exposing. What you're talking about is the OUTBOUND port from your client to the server. THAT one gets a random port, not the inbound side.
The server doesn't need the port number at all since the clients receiving port number will be the same on every instance of the client. This is the "well-known" part. For example, SMTPs well-known port is 25.
But, since the NAT can do port forwarding, the port number the NAT exposes on the internet side can be different than the port exposed by the client to receive connections. The NAT needs to know what IP and port to send the traffic on that port to on the inside network.
So, I'm still confused, why am I not getting it? There is not any kind of guarantee that the port is "well known" at all, that would only work if only 1 thing on the other side of the NAT would forward that port
OK. Your client connects to the server to report itself, right? The port number that the client uses will NOT be the port number that it uses to listen for other clients connecting to it. The port number that the server sees the client using is only temporary and only good for that one connection. It the client contacts the server tomorrow to report itself, it'll probably use a different port number. You cannot use this port number for anything useful. The only important part is the server can learn the Internet visible IP address of the client. That's it.
Now, in order for the client to listen for connections from other clients, it has to open a specific "well-known" port to listen for connections on. What makes this "well-known"?? YOU! You pick the port number that your app is going to use to listen for connections. This is going to be a standardized port number that every client is going to listen on.
Great! Now you've got a port number. Well, your client software has a port number. The user's NAT doesn't know that. So, the NAT has to be configured to forward incomming connections from the public internet to a specific IP and port number on the inside of the network, preferrably the client machine(!), and the port that the client is listening on.
Now, back up a second. The NAT can forward any port number exposed to the public internet to any port number on the inside network. So, you can easily have the NAT listening for a different port number on the public internet, but usually you don't want to do this. Normally, you'd just use the same port number that the client is listening for. Just keep it in mind for troubleshooting purposes.
So, now you've got the NAT listening on your well-known port and forward traffic on that port to the client inside the network. Now, another client starts up, contacts the server to report in and get the list of currently connected clients. Your new client attempts to connect to another client, using the IP address it got from the server and the well-known port number. That request is going to get forwarded to the first client by the NAT, and any response sent back to the new client.
Now, if your clients are only supporting a single connection, you can leave it at this. If your clients are going to be able to talk to multiple clients simultaneously, you'd use this initial connection to negotiate with the calling client a second connection on a different port. The new clinet would have to start a listener on a random port, telling the first client which port that is on the initial connection port. The first client would then open a connection back to the new client to start the communication channel the two clients are going to use to chat with. The initial connection can then be closed down and the first client can then reuse the same port to listen for another connection request...
Ok, but that is bad.. and bittorrent definitely allows this, and they'd basically have the same problem. Now, I know they send the port number to the server as part of the protocol. Is that why it works? Allowing the port to be manually configured and then send it to the server? Because that's definitely something I could do
Guy, read up on how servers work first. Just keep 2 things in mind. Your "client" software is really two pieces - a client AND a server listening for connections. The server side is ALWAYS listening on a well-known port and this channel is used to setup negotiated ports for further communication. All you have to do to find this out is run other client/server software under a network sniffer to find this out. But, that itself requires an in-depth knowledge of how TCP/IP and client/server communication works.
Am I really that stupid? I know how it works normally, I'm just getting thrown off by NAT..
If one could forward the same port twice then I wouldn't have any problem but you can't - making the port unknown.
So in order to hack around that, I thought I could bind to the port (the one that will be listening later) for the outgoing connection so that the server could read the correct port. The documentation of bind suggests that that is possible, but it's not (but from what I know from TCP/IP, it should be). So the only way that I see to get around it is to manually configure the ports for all clients behind the same NAT and send the port number to the server.
The new clinet would have to start a listener on a random port, telling the first client which port that is on the initial connection port. The first client would then open a connection back to the new client to start the communication channel
Won't NAT block that, if you have only setup port forwarding for the well known client port?
Hi All, I am kind of new in programming in c#. Recently I am working on a window base application. The Application has a dataGridView and it fills with data which comes from many diffrent source. The dataGridView display all the data in which order they come.
My Question is how do I print only the data i wanto print. for examlple, the dataGridView has 10 rows. within 10 rows there are three kind of data. I only want to print one kind of three.
Printing fucntion look for only those row that has same data value.
any rows that matches with my selected row should go to print rest should be ignored.
You can find an enlightening MSDN forum post here. That's got many different code snippets on, and a link to an interesting article as well. I would assume that if you only want to print certain rows, then you can go to the piece of code which iterates through each row and check if you want that row. If you do, then draw it; if not, continue to the next iteration
Between the idea
And the reality
Between the motion
And the act
Falls the Shadow
It doesn't do precisely what you want, but it is near enough that you ought to be able to adapt it.
If you try to do that and get stuck, please make a new thread with the code you are stuck on, and exactly what the problem is.
As an alternative, you could give the user somewhere to enter the selection criteria, TextBoxes or CheckBoxes for example, and then only load that data into your grid. There are lots of articles on printing datagridviews.
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
Your sound card manufacturer may provide one, but there is no general standard for this as far as I know.
You can create your own audio player and provide your own DSP in that. Search for Audio DSP C# and you should find something to help you get started.
Dave BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) Why are you using VB6? Do you hate yourself? (Christian Graus)