|
From: Lars <la...@us...> - 2004-08-11 21:10:51
|
Hello there! Me and Wellington spoke earlier today a little about different considerations. Mostly regarding efficiency-concerns with message delivery through a web of servers. I think Wellingtons basic idea about the system is that a client connects using TLS/SSL to a server, and only that server. He can then speak to all clients in the web of servers oblivious to which server the user is actually connected to. This web may contain redundant link (as drawed on the diagrams in ssmt.sourceforge.net) so this raises the question how to avoid messages going in a loop... Also.. a big web with lots of links may raise concerns about overhead if messages are "broadcasted". To clear this second problem we thought that perhaps it would be a reasonable solution for servers to store a cache of where the shortest path to a user is, and when its not in the cache, a broadcast/path-recording - method might be used to discover and record the shortest path. The fork() for each client sounds a bit crude. Since there isnt much data from each client, maybe its better to use select() or perhaps lump together some clients for each fork(). But multiple processes raises concerns about process-communications, for instance if the server is supposed to hold a cache, then each client-process needs to access and change this cache.. i dont know how that would work. I have never used or read about SCTP before, so i can not decide on that one. Server design needs to be clarified, lots of decisions and ideas to think about. Keep the mails coming guys. /Lars icq: 168983314 msn: lar...@ho... > Hi, > I agree with Wellington, when he suggested that we should subscribe to > developer mailing list. > The idea of being all (three?) of us online at the same time would be > great, but as I notice we come from different countries and time > difference is quite big (I'm from Slovenia (Europe)). Anyway, i also use > IRC, my nick is someone_ (someone_!~so...@be...) wich is > _always_ online, even if i'm not there. > > suggestions for server design: > * TCP, concurrent (fork() for each client) (maybe we could use SCTP > between linked servers?) > * message sent from client stores on server until destinated client > connect. Server also sends info about this message (on wich server msg > is located) to other (linked) servers. > * when client wants to recieve msg, it sends request. server wich > recieve request notify server wich holds message, this server opens > connection to a client and sends the msg. > > that's just a basic idea of how server could work. what about (extra) > security, any suggestions? > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > ssmt-devel mailing list > ssm...@li... > https://lists.sourceforge.net/lists/listinfo/ssmt-devel > |