🚀 go-pugleaf

"Ron Sawyer" <XXXRSAWYER8128XQQXX@aol.com> wrote in message
news:45acd81e$1@newsgroups.borland.com...

> The server works fine if the client is on the same network.  But if
I
> try to go over the internet the server and the client do not
connect.

Then the client is likely trying to connect to the server using the
wrong IP/Port.  Is the server running on the machine that is
physically connected to the Internet modem?  Or is the server running
on a machine that is getting its Internet connection through a
router/proxy?  What does your TIdTCPServer setup look like?  How are
you configuring its Bindings collection exactly?

> The address I use is obtained via the ipconfig command.

Indy has its own global GStack.LocalAddresses list that contains the
available IP adresses of the machine.  If the server machine is
physicaly connected to the modem, then are you specifying the modem's
public IP as the listening IP on the server?

> However, the client cannot contact the server from that same
machine.

Yes, it can.  Especially if it is on the same machine.  If it is not
connecting, then either the server is not actually listening in the
first place, or the client is connecting to the wrong IP/Port.


Gambit

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
Remy, I was hoping you would answer - I figured  you would know.

>Then the client is likely trying to connect to the server using the
>wrong IP/Port.  Is the server running on the machine that is
>physically connected to the Internet modem?  Or is the server running
>on a machine that is getting its Internet connection through a
>router/proxy?  What does your TIdTCPServer setup look like?  How are
>you configuring its Bindings collection exactly?
>
The server is on the machine that is physically connected to the internet modem.  The code to connect is:

    int Port;
    Port = Edit1->Text.ToInt();
    TCPServer->DefaultPort = Port;
    TIdSocketHandle *LclSocketHandle;
    LclSocketHandle = TCPServer->Bindings->Add();
    LclSocketHandle->IP = JvIPAddress1->Text;
    TCPServer->Active = true;

JVIPAddress is simply an edit that the JEDI project provides for internet addresses.  The rest is Indy stuff.

>> The address I use is obtained via the ipconfig command.
>
>Indy has its own global GStack.LocalAddresses list that contains the
>available IP adresses of the machine.  If the server machine is
>physicaly connected to the modem, then are you specifying the modem's
>public IP as the listening IP on the server?

This may be the part I'm not doing correctly - it seems possible that I do not know how to obtain my public IP address.  I am going to a DOS prompt, typing IPCONFIG and using the address that comes back.  You mention that Indy has a global stack of address.  I will start looking at that some and see if I can figure out how to obtain the address I want.


>
>> However, the client cannot contact the server from that same
>machine.
>
>Yes, it can.  Especially if it is on the same machine.  If it is not
>connecting, then either the server is not actually listening in the
>first place, or the client is connecting to the wrong IP/Port.

There server is certainly listening.  As mentioned, I run the client on the same machine and it works perfectly.  Only when I have the client run from a machine at work does it fail.  The machine at work can ping me, so it *seems* to me that the address I provide is my public address.  

"Ron Sawyer" <win8128@aol.com> wrote in message
news:45ad2aee$1@newsgroups.borland.com...

> The server is on the machine that is physically connected to the
internet modem.

>     TCPServer->DefaultPort = Port;
>     TIdSocketHandle *LclSocketHandle;
>     LclSocketHandle = TCPServer->Bindings->Add();

Was the server previously active before calling that code?  If so,
then the Bindings collection already had entries in it.  Setting the
DefaultPort has no effect on existing entries.  Make sure the
collection is empty before setting it up with new values.

>     LclSocketHandle->IP = JvIPAddress1->Text;

Setting the IP property locks down the Binding to a specific local IP.
If you leave the IP empty, then the Binding will listen on all
available local IPs.

> JVIPAddress is simply an edit that the JEDI project provides for
> internet addresses.

Is it reporting the correct IP for the modem, though?

> This may be the part I'm not doing correctly - it seems possible
> that I do not know how to obtain my public IP address.

You have to specify the local IP that the server is going to physical
listen on.  If the modem is directly connected to the machine, then
the local IP for that adapter is the same as the modem's public IP.
The GStack.LocalAddresses list will contain that IP.  The IPs in that
list are the only IPs that you can tell the server to listen on.

> There server is certainly listening.

How are you verifying that exactly?

> As mentioned, I run the client on the same machine and it works
perfectly.

Which IP is the client actually connecting to locally?  Since you are
specifying the IP for the Binding collection, you are likely not
adding an entry for the local loopback IP (127.0.0.1).  So I am
assuming that you are specifying the modem's IP when connecting
locally?

> Only when I have the client run from a machine at work does it fail.

Like I said earlier, the client at work is likely specifying the wrong
IP/Port.  Or worse, your work's LAN is probably blocking the
connection.  Many company LANs have firewalls in place to limit what
employees can access.  Did you verify with the network admin that your
client is even allowed to reach your server?

> The machine at work can ping me, so it *seems* to me that the
address
> I provide is my public address.

Not necessarily.  A ping only tells you whether the machine is
physically reachable.  That does not guarantee that a connection to a
specific server runing on that machine will succeed.


Gambit

Remy, sorry for wasting your time.  I had someone from work take the client
home with them and they are able to talk to my server from their house. We
are assuming that the network guys at work have restricted that sort of
communication.

The next big thing is to figure out why the GPS device doesn't talk.  But at
least now I know the server works.

Again, I apologize for wasting your time.