Re: How to identify client connection (TCP Socket)
- From: "Alexander Nickolov" <agnickolov@xxxxxxxx>
- Date: Thu, 16 Mar 2006 11:19:25 -0800
On question 2 - the answer is actually NO. In the presense
of symmetric NAT, the same client may connect to the server
using different public IP addresses.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"Vadym Stetsyak" <vadym_s@xxxxxxx> wrote in message
news:uo3SkiSSGHA.5468@xxxxxxxxxxxxxxxxxxxxxxx
Hello, vlad!
v> Is there recommended practice to identify incoming TCP connections?
AFAIK each TCP connection, according to TCP RFC, is identified uniquely
with
RemoteHost : RemotePort <-> LocalHost : LocalPort
v> For instance. My app has several threads each has connection to server.
v> Each of them transfer different type of data. So I'd like to keep them
v> separate (also to dont mix up fragmented TCP packets).
v> I stuck on implementation of effective identification system. How to
v> assign server working socket to corresponding thread.
If I understood you correctly you have some state that is in separate
thread, and when the request from client arrives you
wake up appropriate thread?
If it is so then...
it is bad idea to bind a thread to particular remote host due to
scalability issues...
You can use a dictionary to get needed data
Smth like
Dictionary<RemoteEndPoint, AssociatedClientState> jobsDictionary;
v> After all I have to get the figure below :
v> Client:
v> - thread 1. socket.localendpoint = 192.168.0.100:2050
v> - thread 2. socket.localendpoint = 192.168.0.100:2051
v> Server:
v> - thread 1. workingSocket.remoteendpoint = 207.x.x.x:2050 <- real ip
v> and same port
v> - thread 2. workingSocket.remoteendpoint = 207.x.x.x:2051
v> Question 1: How properly (and in most simple way) implement handshake
v> between server and client to let server identify valid connection and
v> reject strangers.
It is better to implement custom authentication mechanism, because clients
IP can be spoofed, thus
introducing security hole.
v> Question 2: When client connects under private address (192.168.x) then
v> server outside will see real ip of private network gateway (say 207.x).
v> Is it
v> true that client application will always present outside 207.x.x.x
v> address and not 207.x.x.y (is it possible for gateway to have more than
v> 1 WAN interface ?) ?
Yes
v> I mean how persistent and reliable would be identification by gateway's
v> address ??
v> Question 2.1: even in case of 3-stage handshake - I dont understand -
v> how to tell server which port will open client. I know that client
v> socket gets port number on socket.BeginConnect.... means that it is too
v> late to tell server this port number as it is about to connect
v> server.........
Why? You can bind socket to specific port and IP. Socket.Bind(....);
v> Looks like server has to accept any connection and then wait for
v> confirmation with port number from client (before start send/receive on
v> this socket).... ??? dont like the idea really...
Why do you have to think about how TCP connection is initiated?
--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com
.
- Follow-Ups:
- References:
- Prev by Date: Re: closesocket() blocks and never returns
- Next by Date: Re: closesocket() blocks and never returns
- Previous by thread: Re: How to identify client connection (TCP Socket)
- Next by thread: Re: How to identify client connection (TCP Socket)
- Index(es):
Relevant Pages
|
