🚀 go-pugleaf

My eyes are now open... thanks...
and that is why your Gambit and i am a mere mortal..
Sorry for the slow catch up..



"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:423b4b3b$1@newsgroups.borland.com...
>
> "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
>
>