Alex Tweedly wrote: > Richard wrote: >> This excercise raises a question: rather than invent another protocol, >> why not use HTTP? > > > Usually, because HTTP is quite decidedly a client-server protocol. > If you have a peer-peer protocol need, then you have to bend HTTP > out of shape :-)
Sockets work by having a listening and a caller. Having both on both sides is P2P. What "bending" of HTTP is needed over any similar protocol, like the one being designed here? > Or, because in the event of a breakdown in the firewall, a > mal-intentioned outsider could more easily circumvent your protections. That would also be a concern with P2P, where ports must be opened. And that's also one of the reasons much of the P2P buzz of the early part of this century faded as cloud rose: well maintained firewalls can make devices unreachable. Skype is a good example. Originally designed as P2P with a client-server fallback when blocked by a firewall, it's mostly used via client-server these days. > Or, just because it's more interesting :-) Learning is always a valid reason. I've built and thrown away a good many sytems over the decades, for custom protocols to network DBs and a couple of half-baked CMSes. I don't regret the time invested. Tho these days I tend to use standard tooling where available for the case at hand, the time spent with home-grown experiments gave me a deeper understanding of the problem space, allowing me to use standards a bit better than if I'd come in cold. -- Richard Gaskin FourthWorld.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
