You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Wellington S. C. <ner...@te...> - 2004-08-12 16:16:46
|
Yes someone_, you got the basic idea. We thought that the "slower delivery" will reduce with grow of time, because when the server knows the path, the "broadcast" would not be necessary if a record exists. For instance, the path to the user could be found when the user open the client. A message to the server could be sent with the list of users to be found in the web of servers. Then, the real "user messages" don't be slow because the server already knows the path. It's legible? sorry about my poor english ;)... On Thursday 12 August 2004 12:55, Someone wrote: > I never worked with TLS/SSL, so i don't have any experiences with that > (i know how it works, but thats all).. > > I agree, select() would be better choice. Anyway, don't worry about > interprocess communication - we can simply use UNIX domain sockets. > > Em, did I get this righ? client sends msg, msg goes trough a web of > servers to the server that the other client is connected to? Msg would > go trough the shortest path (how do we know it's the shotest anyway?), > and if path isn't known, broadcast msg is sent to all servers, and one > of them sends back reply with a path? That would mean a lot of traffic > and slower delivery. (sorry, i'm a bit confused about this) > > ---- > About SCTP: (you don't actually need to read this, just for info .) ) > i think it would be perfect for connections between servers, > but not yet - it is still in developement and not all implementations > support it. (It is not good for the clients, since sctp isn't supported > on all systems, besides client need just one connection to one server). > > I'll try to explain basic concepts of sctp here. > Sctp is newer transport protocol, standardized in the IETF in year 2000. > That's probably why you haven't heard of it yet. > It can be used in two styles one-to-one (like tcp, but improved. TCP > applications can be ported to sctp one-to-one style very easily) or > one-to-many. That one i think we could use: > One-to-many style provides an applicaton ability to write a server > without managing large number of descriptors. A singel descriptor > represents multiple associations (much the same way that udp can recieve > msgs from multiple clients.) > So, if you look again at picture > (http://ssmt.sourceforge.net/ssmtdia1.png) again, then you can see, that > if TCP would be used, server A needs to open 2 socket descriptors. one > for connection to server B and for connection to server C. On the other > hand, if we use SCTP, only one socket descriptor is opened (and two > associations), and it can communitate with B and C. btw, functions > send() or write() should not be used in one-to-many style (it's much > better to use sendmsg(), sctp_sendmsg() or sendto()). > you may find more info here: http://www.sctp.de/sctp.html > > anyway, maybe that's not best idea, since most users will have to > rebuild their(well, to tell you the truth, i would have to rebuild my > own too.) kernels to support SCTP and we all know TCP much better. > > ** I suggest to keep using TCP. ** > (we will have much less problems, believe me .) ) > > > ------------------------------------------------------- > 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 |
|
From: Someone <urh...@si...> - 2004-08-12 15:55:31
|
I never worked with TLS/SSL, so i don't have any experiences with that (i know how it works, but thats all).. I agree, select() would be better choice. Anyway, don't worry about interprocess communication - we can simply use UNIX domain sockets. Em, did I get this righ? client sends msg, msg goes trough a web of servers to the server that the other client is connected to? Msg would go trough the shortest path (how do we know it's the shotest anyway?), and if path isn't known, broadcast msg is sent to all servers, and one of them sends back reply with a path? That would mean a lot of traffic and slower delivery. (sorry, i'm a bit confused about this) ---- About SCTP: (you don't actually need to read this, just for info .) ) i think it would be perfect for connections between servers, but not yet - it is still in developement and not all implementations support it. (It is not good for the clients, since sctp isn't supported on all systems, besides client need just one connection to one server). I'll try to explain basic concepts of sctp here. Sctp is newer transport protocol, standardized in the IETF in year 2000. That's probably why you haven't heard of it yet. It can be used in two styles one-to-one (like tcp, but improved. TCP applications can be ported to sctp one-to-one style very easily) or one-to-many. That one i think we could use: One-to-many style provides an applicaton ability to write a server without managing large number of descriptors. A singel descriptor represents multiple associations (much the same way that udp can recieve msgs from multiple clients.) So, if you look again at picture (http://ssmt.sourceforge.net/ssmtdia1.png) again, then you can see, that if TCP would be used, server A needs to open 2 socket descriptors. one for connection to server B and for connection to server C. On the other hand, if we use SCTP, only one socket descriptor is opened (and two associations), and it can communitate with B and C. btw, functions send() or write() should not be used in one-to-many style (it's much better to use sendmsg(), sctp_sendmsg() or sendto()). you may find more info here: http://www.sctp.de/sctp.html anyway, maybe that's not best idea, since most users will have to rebuild their(well, to tell you the truth, i would have to rebuild my own too.) kernels to support SCTP and we all know TCP much better. ** I suggest to keep using TCP. ** (we will have much less problems, believe me .) ) > Date: Wed, 11 Aug 2004 23:10:44 +0200 > From: Lars <la...@us...> > To: ssm...@li... > Subject: Re: [ssmt-devel] Server design > > 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... |
|
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 > |
|
From: Someone <urh...@si...> - 2004-08-11 20:30:49
|
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? |
|
From: Wellington S. C. <ner...@te...> - 2004-08-11 05:15:28
|
hello... |
|
From: Wellington S. C. <ner...@te...> - 2004-08-07 13:17:04
|
just testing. |
|
From: Wellington S. C. <ner...@te...> - 2004-08-07 13:02:38
|
testing |