|
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 |