just want to suggest that you don't need to have active clients indicate
their status at the server that precisely. they just need to "log in"
showing their IP, but don't strictly need to "log out". every time a
client requests the list, the server purges their previous list entry
(if any), sends the client this new list, and then appends their IP (and
timestamp) to the bottom.
when a client tries to connect to another client (off of the server
list), it may or may not be able to connect.. even if the target client
is active, internet conditions beyond anybody's control may inhibit the
connection. it's perfectly within the P2P concept to let clients
determine each others availability at connection time: if the initial
handshake packet is not returned, just go on to the next listed client
an try that one.
this eliminates need to update the list at log-off, and interrupted
sessions, as well as things like IP-renewals and line outages. they are
going to happen, and its more reliable and process- and
traffic-efficient to deal with this at the client-to-client level.
the client list at the server server should keep both the client IP and
the last timestamp of the client's login, and the server can purge the
list periodically for obsolete logins based on a timeout period. clients
can apply the same timeout period to skip attempts at obsolete entries:
if this particular client appears on the list again its because it
recently requested a new list from the server.
clients only need to download a new copy of the list when they log in,
and when they have traversed their last one. assuming that the goal is
to keep all clients updated with each other's files, clients will keep
checking each other on a continuous rotation.
using a pool of threads, clients can balance their process and
connection loads as needed on their host platform, determined at their
initialization, based on available RAM and bandwidth. the more
efficiently they can traverse their server lists, the more often they
will log back in to request new ones. the clients also want to skip
attempts to remote clients on the current copy if the list who have
already requested and connected successfully.
finally, along with the list of available clients, the server can also
pass along parameters such as the timeout period and guidelines for
thread pool size calculation. a second timeout parameter, to inhibit
connections to recently connected clients, can help balance the loads
and insure that clients that have not been queried recently get priority
(this means that clients must keep an internal list of recent client
connections). its nice to be able to tweak these things through the server.
client psuedocode:
process init (determine thread pool size)
main loop:
download client list (and parameters, maybe adjust thread pool)
while traversing list:
if threads available,
check for and accept remote client connection requests (spawns
remote_connection threads)
if thread available and not already connected to this client
connect to next client in the list
if connected, spawn local_connection thread
end (while traversing list)
end (main loop)
local_connection thread:
try
get remote client's file list
if needed files
get needed files
respond to remote requests
finally
disconnect
remote_connection thread:
try
handshake
respond to remote requests
get remote client's file list
if needed files
get needed files
finally
disconnect
hope this helps.. the first app i ever wrote was a distributed
library-loan request forwarding app, P2P before its time (it was modem
based, before the public internet!). there was no server, clients
updated each other's lists of phone numbers to call, making sure their
own was listed. a new client would only need one valid phone number to
inject itself into the network. phone numbers that didn't respond for a
month were purged from the list. ugly by today's standards, but it
worked fine.
[EMAIL PROTECTED] wrote:
>
> If I choose Christianity then the Islamic will say I'm a pagan.
> If I choose Islamic then the Buddhism will say I'm a pagan.
> If I chose Buddhism then the Jewish will say I'm pagan.
> If I choose no God then everybody will say I'm pagan.
> Please, can I be free? Can you NOT tell me how I should live MY life?
>
who cares what others think or say? if we are answerable to a god, thats
between us and that god. and if we're not answerable in that way, we
certainly don't need to account to each other on the matter! NB: gods
that instruct people to argue with each other about this are suspect.
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk