🚀 go-pugleaf

Actually now you mentioned about kazaa members connected to the Kazaa DB
server...

The way i have is is the Application post the logon details to the website
php every x amount of minutes to update there last logon time and the server
when it gets a search request from another pc builds the results and uses
last logon time of the found data records to decide whether to flag them as
offline of online and displays the correct img..

Is this a usable way or should it be using sessions, stay alive etc..



"roger" <rogersmail@ntlworld.com> wrote in message
news:423bc2df@newsgroups.borland.com...
> 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
> >
> >
>
>