|
According to the subject the first part of my answer is about TCP connections, where a server listens on a socket and one or more clients can connect to the server.
The terms server and client are well defined in this context.
|
|
|
|
|
But you werent using client and server in that sense of a socket connection, you were using it in terms of network computers: "So two clients can not communicate even when in the same network segment."
==============================
Nothing to say.
|
|
|
|
|
Nit-pick.
A system that provides a service using a listening socket (or other methods) is a server. A system that connects to a server is a client. A system may be server and client at the same time.
|
|
|
|
|
Nit pick? You are talking crap saying you need a service to pass communicaitons on between machines on a network. You confused the socket and network terms for client and server and gave the OP the wrong answer.
==============================
Nothing to say.
|
|
|
|
|
You should let the OP decide how to treat my answer. Maybe you can help him by giving an applicable answer (ping does not help him because both systems are probably behind routers using NAT).
I confused nothing. I just have another view and understand that this view is not follwed by everyone. By accepting this view, there is no problem to understand what I have said. But claiming it as crap shows that you did not give at try.
EOD
|
|
|
|
|
Jochen Arndt wrote: both systems are probably behind routers using NAT
That is what we need to establish. If so, then he is into a more complex design. But it is possible that all he needs to do is open a few ports on the firewall.
OK, I admit, I reacted to the terminology you used, understanding it to mean something else so I will apologise for saying 'crap'. 
==============================
Nothing to say.
|
|
|
|
|
Erudite_Eric wrote: That is what we need to establish. If so, then he is into a more complex design. But it is possible that all he needs to do is open a few ports on the firewall.
I think it has been already found out to be so. Opening ports may be not possible when prohibited by company policies. Because we did not know about the network topology that should be covered, the OP should give us more details. But may be he already decided what to do.
Erudite_Eric wrote: OK, I admit, I reacted to the terminology you used, understanding it to mean something else so I will apologise for saying 'crap'.
Thank you. I appreciate that.
|
|
|
|
|
Yes, he replied to me saying that he cant open ports "for some reason". If this is the case it seems like he isnt going to be able to get any custom TCP coms working.
==============================
Nothing to say.
|
|
|
|
|
Actually... I think you're wrong on this one.
|
|
|
|
|
I am not wrong to suggest that the basic set up of the networks need to be established before recomending creating services to translate IP addresses between two subnets.
==============================
Nothing to say.
|
|
|
|
|
That's about the only thing you're not wrong about... and even at that, being able to ping does not infer complete connectivity. Ping is a specific service on a specific port. I have some of my computers configured not to respond to pings. As a matter of fact, you can't ping most of Microsoft's web servers, we had a conversation about this in the lounge not too long ago. On top of that, firewalls can block ping messages.
|
|
|
|
|
Yes, for sure, but if the ping port IS open and he cant ping then he has routing/NAT issues, and he will have to implement a design as suggested by various people here.
If he can ping, then he can connect one client direct to the other.
==============================
Nothing to say.
|
|
|
|
|
Ouch, that's a little harsh. "Client - Server" is a concept / term that confuses a lot of people. A lot of people think "Server" in a hardware-like way, that is, some machine technically designated as a "server", running "server software" like "web services", "database services", Windows Server 2008, etc.
However, for some people, "Client - Server" is more like "Pitcher - Catcher", one system "initiates" a connection (the Client), the other "waits / receives" the connection (the Server). This is the TCP model, both machines cannot "initiate" the connection and have it work, there is one "connector / pitcher" and one "receiver / catcher". Many people, I and Jochen included, call this "client - server".
Where some people become confused is that, at any moment, a particular machine can both initiate a connection somewhere (be the client) and have ports awaiting connection (be the server). I once knew a guy who just couldn't get his head around that idea. Even when I explained that when he was in the lab using a database server machine and ran IE to open a web page, that IE was the "client" and the target web site was the "server".
So, in some sense, TCP *does* have sod to do with clients and servers, the "conceptual kind", not the "physical kind".
|
|
|
|
|
Thank you for the excellent clarification.
|
|
|
|
|
Chuck O'Toole wrote: Ouch, that's a little harsh. "Client - Server" is a concept / term that confuses a lot of people.
Aparently so.
This guy even confuses socket architecture and network architecture, hence his dumb reply about a 'service' on the 'server' that ca forward coms to/from network clients.
Sheer bull. If you can ping form one client to the other then you can route a socket between them which ever end is the sender or receiver.
Harsh? Maybe. But stupidity needs to be stamped out quickly incase it becomes infectious.
==============================
Nothing to say.
|
|
|
|
|
Well, I think we've lost sight of the OP's question,
OP wrote: I want to let two client create TCP connection. These two clients are in different LAN, and there are firewalls, so these clients do not have WAN IP. But there is a server that these two client can visit.
Is there a way to create TCP connection between two clients through server?
Clearly, he cannot "ping" one another as neither has a "WAN IP", which I take to mean that there is no way to identify the IP of one machine to the other. It is the OP that raises the need for an intermediate "server", which Jochen suggests could provide a Pass-Through from one "LAN" to the other but that pass-through needs to be well thought out and is probably complicated by the firewalls.
Now there are other ways of getting the two machines (I am purposely avoiding calling them "clients") to see each other, including opening ports on the firewall, etc. However, without knowing the nature of the firewalls, it's impossible to provide suggestions. For example, how I'd do it on the Linksys box in my house is very different than how I'd do it on the corporate firewall my company uses (assuming the IT department would even let me do that).
Personally, I'm inclined to cut Jochen a little slack here, his answer was reasonable considering the OP's question.
|
|
|
|
|
Whatever he does he os going to need to use open ports on the firewall or open some more. THats for sure.
As for being on seperate LANs it depends on the routing whether he can ping or not. Thats the frst thing to establish.
==============================
Nothing to say.
|
|
|
|
|
|
I find that the word 'client' can misguide you. The word 'application' can be better.
Let me re-explain this problem again.
I want to design a network application that can send and receive data using TCP protocol. Certainly, these application can listen the socket port if need.
The problem is that if two applications in two different LAN, without WAN IP because of FireWall, how to create TCP connection between these two applications.
Normally in different LANs, if one application as the server, it must have a WAN IP so the other application as the client can connect to it. But now these two applcation also do not have WAN IP, how to create the TCP connenctions?
I guess that the emule uses this way to transfer data between two clients with low ID. But I do not know how to achieve it.
|
|
|
|
|
I understand the problem. Your systems are not only behind firewalls, but also behind routers that do NAT (network address translation) [^]. So the systems can't be seen from the "outside".
One solution would be to design your software as usual and change the network setup on the side that has a listening 'server'. This requires that the client side knows the WAN IP of the server side. If that IP is not static (dynamically assigned), you need to register at a dynamic DNS service like DynDNS and update the IP when getting a new dynamic one (routers usually have an option to do this). So the client can determine the server-side IP using normal DNS queries. Even with a static IP, you must configure a port forwarding on the router at the server side. This will forward packets from the WAN to a specific port on the local server system and vice versa.
Pro: Your software can be written as usual (like any other network software).
Con: Router / firewall must be configured. That may be restricted by policies when used in companies.
Another option is writing a special service application hosted on a system that is accessible from all clients and performs some kind of data forwarding. You are right, Emule and other file sharing applications do so. The service application stores a list of all connected clients that can be queried. The clients can then pick up other systems from the list and communicate using the service application.
Pro: No router / firewall setup changing necessary.
Con: Requires definition of an own protocol and writing the service application.
|
|
|
|
|
Can you ping from one client to the other? If so a route is available and a socket can be opened. SPecify a port that is open on the firewall.
==============================
Nothing to say.
|
|
|
|
|
No. And can not open the port on the firewall for some reason.
|
|
|
|
|
Is the ping port blocked then?
If you cant open ports then I dont see how you can get any kind of custom IP comms round the network.
==============================
Nothing to say.
modified 16-Feb-12 7:05am.
|
|
|
|
|
Yes, but you would need to create a TCP server app that accepts messages from one client and forwards it to the other, and vice versa. It's just a mater of designing your own private message protocol and adding that to your client and server apps.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
yu-jian wrote: Is there a way to create TCP connection between two clients through server?
I am almost positive that this is the wrong forum for this question. You would probably get some responses from network administrators in the System Admin forum[^]. But since we are in an ocean of wrongness I'll throw you a lifebuoy.
If I understand you correctly... you have something like:
[Network A] [Network B]
\ /
[Dumb switch]
|
[Server]
It doesn't matter if my graph is wrong and you actually have multiple Layer 1 network switches/routers on segregated networks. If both networks are able to speak TCP with the server then; Yes you can use the server to route packets between the subnets. You would set the server as the 'Gateway' and setup some static routes[^]. If the server is running Linux... same thing... same route command[^].
Another option if you are able to use UDP rather than TCP would be Multicasting[^]
Also... there are alot of IFs ANDs and BUTTS (butt-heads too) when it comes to network questions. To get a definitive answer it would be better if you drew a network graph. If there are any Layer2/Layer3 devices between your server and sub-nets it complicates the issue; but only slightly.
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
