Win a copy of Terraform in Action this week in the Cloud forum!

George Bonfield

+ Follow
since Nov 07, 2011
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by George Bonfield

Rob Spoor wrote:Let's BeNice, shall we? If not I will close this thread.

George, you've already been told that you can only connect to your LAN server while using the public IP address with NAT loopback enabled. Perhaps you don't understand why, but those are the clear facts, whether you like it or not. If you are unable to enable LAN loopback because your router / firewall does not support it, then there is nobody that can help you.

I have to clear this one up, if no other issue for today.

I can connect to my LAN server from a client within my LAN which is *emulating* a remote client, by addressing the server via its public IP address. But, Rob, as far as I am aware, *no* NAT loopback is enabled. The only feature enabled on the router which can be said to generically resemble a loopback, is that the router has an inbound rule in operation to send all traffic on the appropriate ports to the LAN server (where *my* server code is running to pick it up). This arrangement I construe as Port Forwarding - (whether it is or not actually true port forwarding in a technical sense, you are all welcome to correct me on if you wish). But there is no formal setting nor implementation of any other kind of router or LAN-wide loopback going on anywhere here at all.
I hadn't realised that a) there were posts here waiting (I have been offline, due to illness), and b) that my crossposting was so troublesome.

But c), I am now blinded by confusion. What I'd like to say there is that - believe it or not - I understand (and understood indeed), what you guys are trying to say, but somehow that has got lost in the fog (my fault I am prepared to accept).

The present position is that the code works fine, (after re-positioning the secondary server back in the server proper), but part of my original question still remains. If I may (and believe me i am not ungrateful for the comments that have been offered), I will rephrase the meaning of my question for you further consideration.

At this point, if any of you would be in a position to want to try out my code, I would be even more grateful.


I need an interlocutor to be at the other end of my programme. Any takers? (Nothing bad will come of it). ;)
Actually my guardian doesn't need to read the address on my outgoing stamped mail, because that will get done in the sorting office. All he needs to do is to keep a count of the number of letters I send, and as long as the count of letters back to me is <= the number of letters I send, then he's happy. But should an extra one arrive, he bins it.

Jeff : from one greenhorn to another, please come back when you understand my issue.
Yep -I absolutely understand those IP differences. And if you'd read my posts properly, you'd realise that I knew that, and that I'm not contending that is my problem. I'm don't need nor attempt to send my private IP to any part of the programme or the internet, least of all the server,since it will obtain it from the socket connection, putting it de facto out of my hands, unless I have some reason to query the socket for it later.
I live in a house. My house has an address. In that house, I have my own room, perhaps a bedroom with en suite.

All the mail that comes into the house, is addressed to a particular person, me being one such.

For reasons that matter to no-one except me, I cannot leave my room.

If I want to send mail to others in the house, I simply write their name on the envelope.

My guardian (who also lives in the house), delivers all mail. Letters come for me regularly - all from people I've written to first mind you. (After all, no-one wants to be the first to start correspondence with a freak). The guardian knows, and implements, this rule tightly. So he brings letters to my room on that understanding. The only people I don't need to write to first, before receiving a letter, are the others in the house, since we are all known to the guardian a priori.

Sadly, I send letters to myself sometimes too. They don't need a house address, only my name, just like the others. (I just give them to the guardian, who hands them right back to me). For good measure, I write my name on the back of the letter, so he knows what to do with it if I am not there. (That was a joke).

One day, just for fun, I decide to spend all my money on a stamp, and write a 'proper' letter to myself. I get someone on the street to post it for me. Next day, it comes back, and the guardian thinks he recognises the handwriting, but he can't be sure, thinks it may be a spoof, and decides to throw it in the bin. I'm left puzzled, because I thought the same rule would apply to that letter as apply to any I send myself in-house. Wrong; 'new' rule. The same rule applies if I try to send a franked letter to someone in my own house.

Making matters slightly worse, if they can be worse, is the censorship of my mail extending to any supernumerary letters which I receive; in other words, if I am in an ongoing written dialog with someone, if they send me even one extra letter, it gets binned, since it doesn't tally with my outgoing missives. This regime quickly impoverishes the nature of my correspondence, making the process of communication pedestrianly and unappetisingly slooooooooooooow. A lot of good information goes into my guardian's bin liner.

On the bright side, those years' of internal scriptural exile pay an ultimate dividend, when I realise I've stumbled across the methodology to allow the invention of the internet.
Thanks. I won't be fiddling with my firewall however.

I don't profess to be an arch techie, and some low-level knowledge of router circuitry and IP packets eludes me. But one thing, as a programmer, I do know, and that is that if a contingency exists, then you have to accommodate (provide for) it within your system. This is clearly something that NAT technology fails in, and it surprises the life out of me that this meta-point has been overlooked or ignored by the designers. As I said in my previous so-called 'hand-waving posts' - (waving always being preferable to reciprocation) - if the thing works in a LAN, then at that point, my job ought to be over.
Let me finally add this in response to Paul's last:

I neither want, nor need, a real deployment of my code to do what I am doing; if a LAN client here wants to connect to the server here, it'll have to do so using the LAN address - and that's completely fine.

Because then, if my client is connected, and 'your' remote machine connects, then our clients can communicate, and as far as I can see, the on-the-fly created troublesome socket will be operational. But it can't be *tested* locally (i.e. LAN-based, with a public IP connecting client as one of the clients), and that sucks.
I do understand the relevance of the NAT. However, I am not sure that you understand the pathology of this problem in the way that you need to.

To quote one of your recent facts, you say that your machine doesn't have a public IP. Fine. But it is connected to the internet, and so it has a public IP at the level of the router or proxy, wherein routing tables are kept to route the return packets back to the right machine - yours. So far so good.

If you were running my code on your machine, you'd be asked in a pop-up window to point it at the IP address of my server, which happens to be behind a NAT.

The two "routers" would know the end-to-end points for the traffic, and that would all work.

Your interface would then for some business reason we don't need to rehearse here, offer you the option of doing some other task with my server, for which another socket needed to be opened. At this point, the most convenient way of getting that link up and running quickly and according to the stochastic nature of the decisionmaking process on the client, is over a socket which your client needs to wait for - ie it needs to open a Serversocket. Your client obtains my server's IP from the socket address of one of the other already open sockets, and uses it along with a predefined port, to wait for the server to request an .accept() your end, and transfer a Vector via an ObjectOutputStream. None of this is rocket science, and none of it should surpise nor overhaul the capabilities of the routers to identify and resolve the origins and destinations of the packet exchange. And that's why it would all work between our machines, despite you not evidently having a public IP.

But the moment I emulate your machine in that scenario on my LAN, the objSocket at 30312 socket throws a fit, and thinks there is only one entry in the routing table, and that entry is for itself.

Feel free - you can have a copy of the client (and the server if you like), and the proof of the pudding will be forthcoming.

You're trying to connect from inside your LAN to outside your LAN to back inside your LAN.

I concur. That's exactly what it is. And that's the only way to emulate the real world, when you can't do it any other way.

Another irony here is that a machine such as yours, which is probably also behind a NAT, will receive return packets from my NATted machine, so it's not as if the routers can't work out where the packets should end up, so where is that information gone when the LAn client wants to connect back to itself from a remote-**looking** IP? That's what grinds my gears.

You need to enable LAN loopback for that to work.

AFAIK, there is no way to implement a LAN-wide loopback, - (which AFAICS would only mirror the entire problem down the hallway) - only a single-machine loopback is possible. Kick me if I'm wrong.
In any case, I expect my code *would* work if it were served on this machine, connected to your machine on a true remote IP, and then tried to connect back to this server using your public IP - that would work.

What won't work is me emulating that here, except that I haveto emulate *"your"* computer by getting one of my clients to address the server via the public IP.

Okay. So let me ask you a theoretical question: You're running a server which accepts connections from clients on the Internet. So would you expect to be able to accept a connection from the computer I'm using right now?

Of course I would expect to be able to accept a connection from your computer - if your computer were running my software.

And if so, would you expect to be able to connect back to it (assuming your application was running here) in the way you are wrestling with now?

Yes, if by "it" you mean my programme running on your machine - provided your firewalls were open on the right ports, and that when your client (which is now a partial server) has approval from the user via a response delivered over one of the existing sockets, then sure.

As for a proxy server, I don't know where that fits into anything.
And that brings me back to my question - what does one have to do to overcome the fact that the socket to allow such a relationship, is refused?
Sorry - did I miss something here?

I am already running a server over the internet - the rest of this application serves clients over the internet. Did you not understand that originally?

The problem is that in one particular method, it is convenient and desirable for the server to call a serversocket on a client (we don't need to discuss why that is). And it is at that point that the connection collapses. But only on that socket. The rest keep working.

I can't repeat the scenario again here any more.
Your admonishments are of course pretty ridiculous for a number of reasons, not least of all because they would effectively spell the end of the internet if they were ever implemented. One machine can act as a server or client, depending on the application in hand, and that's precisely why in- and outbound rules exist for routers and firewalls.