🚀 go-pugleaf

"Chris" <computer@programmer.com> wrote in message
news:45a5011b$1@newsgroups.borland.com...

> I have a Server Socket Program and I have a Client Socket
> program. On my LAN these two programs work like a charm, but
> when I try to access my Server Socket from a computer outside
> of the Network(over the internet) I get an error:

As you should be.  Your client needs to connect to the router's public
IP/Port, not the server's private IP/port.  And the router needs to be
configured for port forwarding as well.  Which it sounds like you are
doing, so something else has to be blocking the connection.

> On the router, which is the only firewall we are using, we use port
> forwarding to connect to the ServerSocket computer. Therefore the
> address of 123.45.67.89:6111 should connect me to 192.168.1.17
> from outside of the LAN. This does, in fact, work for other programs
> like Ultra VNC, but not for my SocketServer program.

Then you are doing something else wrong.  Make sure that your client
really is trying to connect to 123.45.67.89:6111 and not
192.168.1.17:6111, and that the SocketSever program really is
listening on 192.168.1.17 on the port that is being forwarded to.
What kind of server socket component are you using (if any)?  How are
you binding it when starting to listen for connections?


Gambit

>
>Then you are doing something else wrong.  Make sure that your client
>really is trying to connect to 123.45.67.89:6111 and not
>192.168.1.17:6111, and that the SocketSever program really is
>listening on 192.168.1.17 on the port that is being forwarded to.

I do this. I have a text box where I can manually type in the 
address, "123.45.67.89:6111". The SocketServer program is 
running on 192.168.1.17 and listening on the same port. It 
works on the LAN, so I know the server program is listening 
correctly. 

>What kind of server socket component are you using (if any)?

I am using the TServerSocket Component from Borland's C++ 
Builder 6. And on the client side I am using TClientSocket. 

>How are you binding it when starting to listen for 
connections?

I really don't understand what you mean by "binding it". I do 
know that with the TServerSocket Component, when I 
set "ServerSocket1->Active = true;" the Socket begins to 
listen on its specified port at that moment. All I do then 
with my Client Application is Set 
ClientSocket1->Host = "123.45.67.89:6111"(or "192.168.1.17" on 
the LAN, which works) then,

ClientSocket1->Port = 6111;
ClientSocket1->Active = true; 
ClientSocket1->Socket->Connect(0);

(The above works on the LAN as well)

Chris

"chris" <computer@programmer.com> wrote in message
news:45a5472e$1@newsgroups.borland.com...

> The SocketServer program is running on 192.168.1.17 and listening on
the same port.

Are you absolutely sure of that?  It is possible for a server to say
it is listening but actually isn't, or is listening on the wrong IP
adapter.

> It works on the LAN, so I know the server program is listening
> correctly.

Then the fault is likely with your router not forwarding the
connection properly.

> I really don't understand what you mean by "binding it".

A socket connection is uniquely identified by the combination of the
local IP/Port that it is bound to and the remote IP/Port that it is
connected to.  When a client socket connects to a server, or a server
socket begins listening, it has to first bind itself to a local
IP/Port.  This binding tells the OS which network adapter(s) to use
for the socket.  A machine can have multiple adapters installed, so it
is important that the socket use the correct one(s).

> I do know that with the TServerSocket Component, when I
> set "ServerSocket1->Active = true;" the Socket begins to
> listen on its specified port at that moment.

Not necessarily at that exact moment.  If you are using the server in
non-blocking mode (which is enabled by default), then the listening
begins asynchronously.  The speed in which the server initializes
itself is tied to the speed in which the message queue processing
window messages.  So it is possible that your client tries to connect
before the server socket is actually ready for it.

> All I do then with my Client Application is Set
> ClientSocket1->Host = "123.45.67.89:6111"
> (or "192.168.1.17" on the LAN, which works)

You can't specify the Port number in the Host property like that.
That type of syntax only works in third-party libraries that accept
URLs as input.  That is not the case here.  That in itself very well
may be why you are getting an error - TClientSocket (and the OS in
general) can't pasre a port number out of the Host like that).  You
must separate the Host and Port properly, ie:

    ClientSocket1->Host = "123.45.67.89";
    ClientSocket1->Port = 6111;

> ClientSocket1->Active = true;

TClientSocket also has a non-blocking mode available (which is enabled
by default).  Setting the Active property to true (or calling Open())
begins an asynchronous connection in that mode, again tied to window
message processing, and the connection is NOT established right away.
You cannot safely access the socket until the OnConnect event is
triggered in that situation.

> ClientSocket1->Socket->Connect(0);

Why are you using that?  Get rid of that.  Never call Connect()
directly.  That is for TClientSocket's internal use only.


Gambit

Greetings,

I am not an expert, I am a beginner.

But,
I had this exact error.

My problem, as explained by Remy, was :

"The only way for that to occur is if you have the TServerSocket's Service
property set to a non-empty string.  When you do that, TServerSocket
dynamically queries the port number that is associated with the specified
Service provider.  Obviously, you are setting the Service to an invalid
value.  You should get rid of the Service property value altogether and just
set the Port property directly instead."

And indeed, I had wrongly entered a name for the service.

Perhaps that is your issue too?


Q.


"Chris" <computer@programmer.com> wrote in message news:45a5011b$1@newsgroups.borland.com...
>
> "Windows Socket Error: The requested name is valid and was
> found in the database, but it does not have the correct
> associated data being resolved for (11004), on API 'ASync
> Lookup' "