🚀 go-pugleaf

"roger" <rogersmail@ntlworld.com> wrote in message
news:423b3d0f$1@newsgroups.borland.com...

> Mr joe that has just sent me a command from his client to my
> server(my PC)

Meaning Mr. Joe connected to the router, which then forwarded the command to
your server.

> has had data returned to him from my pc

Mr. Joe will see the data come from the router, not you directly.  As far as
he is concerned, the router is the server, and as far as your server is
concerned, the router is the client.

> therefore a relative link using ie.. img src="\images\somepic.jpg"
> wouldn't work...

Yes, it will work.  Mr. Joe has to use your public Internet IP to reach your
server in the first place.  From Mr. Joe's perspective, the page came from
your Internet IP to begin with, so any page generated by your server will
have your Internet IP as the base address for all relative links contained
on that page.  It is Mr. Joe's responsibility to resolve relative links into
absolute ones before making new requests, by prepending the base address of
the page onto the front of the relative link being processed.  Thus
producing an absolute link that still refers to your Internet IP.  When he
makes a request for that URL, it will arrive at the router, which will then
forward the request to your server for processing.

So, given the URLs you have shown so far, here is what actually happens when
your Internet IP belongs to a router:

Step 1)

    Mr Joe wants to request "http://InternetIP:10245/cmd?action=&talk".  Mr.
Joe connects a socket to InternetIP:10245 and issues a "GET
/cmd?action=&talk" command.  Mr. Joe has no concept that InternetIP:10245 is
a router and not the server directly.  The router accepts the connection,
connects to the private IP of your server, and forwards the command.  Your
server accepts the connection and receives the "GET /cmd?action=&talk"
command.  Your server has no concept that the client is a router and not Mr.
Joe directly.  Your server sends back a page to the client contains a
relative link to "/images/somepic.jpg".  The router receives the reply and
forwards it to Mr. Joe.  Mr Joe receives the reply, thinking it came from a
server running on InternetIP:10245 directly.  From Mr. Joe's perspective,
the base address for the page is "http://InternetIP:10245/" and the page
name is "cmd".

Step 2)

    Mr. Joe processes the page and wants to request the image.  He sees that
the relative link starts with "/", meaning that the image path begins at the
root level of the same server that the page came from.  He trims out the
IP:port from the page's base address and prepends it to the image's URL.

Step 3)

    Mr Joe wants to request "http://InternetIP:10245/images/somepic.jpg".
Mr. Joe connects a socket to InternetIP:10245 and issues a "GET
/images/somepic.jpg" command.  The router accepts the connection, connects
to the private IP of your server, and forwards the command.  Your server
accepts the connection and receives the "GET /images/somepic.jpg" command.
Your server has no concept that the client is a router and not Mr. Joe
directly.  Your server sends back the image.  The router receives the reply
and forwards it to Mr. Joe.  Mr Joe receives the image, thinking it came
from a server running on InternetIP:10245 directly.


Now, using the same URLs again, here is what actually happens when your
Internet IP does not belong to a router, but to the server directly:

Step 1)

    Mr Joe wants to request "http://InternetIP:10245/cmd?action=&talk".  Mr.
Joe connects a socket to InternetIP:10245 and issues a "GET
/cmd?action=&talk" command.  Mr. Joe has no concept that InternetIP:10245 is
the server directly.  Your server accepts the connection and receives the
"GET /cmd?action=&talk" command.  Your server has no concept that the client
is Mr. Joe directly.  Your server sends back a page to the client contains a
relative link to "/images/somepic.jpg".  Mr Joe receives the reply, thinking
it came from a server running on InternetIP:10245 directly.  From Mr. Joe's
perspective, the base address for the page is "http://InternetIP:10245/" and
the page name is "cmd".

Step 2)

    Mr. Joe processes the page and wants to request the image.  He sees that
the relative link starts with "/", meaning that the image path begins at the
root level of the same server that the page came from.  He trims out the
IP:port from the page's base address and prepends it to the image's URL.

Step 3)

    Mr Joe wants to request "http://InternetIP:10245/images/somepic.jpg".
Mr. Joe connects a socket to InternetIP:10245 and issues a "GET
/images/somepic.jpg" command.  Your server accepts the connection and
receives the "GET /images/somepic.jpg" command.  Your server has no concept
that the client is Mr. Joe directly.  Your server sends back the image.  Mr
Joe receives the image, thinking it came from a server running on
InternetIP:10245 directly.


See the similarities?  At no point in either scenerio do either the server
nor Mr. Joe have any concept that a router is involved or not, nor do they
need to know.

> as it his his Pc that generates the links..

That is not how links work.  You have the wrong perspective on how HTTP
actually operates.

> I know what you are saying Gambit is correct, but were not talking about
the
> same type of program i dont think...

Then you need to proide SPECIFIC details about what EXACTLY you are trying
to accomplish.

> The nearest program i could describe it too although its a different line
> is Kazaa etc.. they search the kazaa website and then get what they
> want from the users pc..

Kazaa works in the same manner as described above.  A Kazaa client searches
the database and gets the Internet IP for a user that has the desired file.
Then the client connects to the Internet IP, regardless of whether a router
exists, requests the file, and receives the file.  It is the router's
responsibility to ensure that the data exchange properly flows to/from the
appropriate private machine on the router's network.

Now, with that said, there is another scenerio you have to consider - a
router exists but is not confiqured properly.  When a client tries to
connect to the Internet IP in order to request a file, the connection may
not work properly (obviously).  So how do you get around it?  By reversing
the roles of the two parties involved.  The user requesting the file creates
a server socket, and the user who has the file creates a client socket.  The
user who has the file connects to the user who wants the file and sends the
file to him, rather than the other way around.

But then, how does the user who has the file know where to send it to?
Simple - both parties have to be connected to the same public server, who
then keeps track of the Internet IPs of every user so it can tell each party
where the other party is located.  That is exactly how Kazaa, and also IM
services (ICQ, AIM, etc) work - everyone is connected to the main database
server, who then knows where everyone is.  When one user wants to establish
a connection with another user, the main server has to act as an
intermediary while both parties negotiate to decide whom will connect to
who.  If one user cannot connect to another, then they try reversing the
direction of the connection and try again.  A router may not be able to
route incoming connections from the outside world to a private machine, but
a private machine can always make an outgoing connection to the outside
world.  Once the connection is established, it doesn't matter who sends
commands and who processes them.  Sockets are bidirectional.  The user who
is arunning the server socket for the connection can still be the one to
send commands to the user who is running the client socket for the
connection.

There is one last issue to consider - both parties are each behind a router.
At least one of them must be configured to forward data properly, or else
neither party will be able to connect to the other at all.


Gambit