I've implemented many custom protocols and process managers, and have implemented a few RFC-standard protocols with raw sockets and with MV BASIC, so I have some experience in this area.
> From: John Jenkins > For anyone currently using Message Queues - please > switch to sockets - I speak from personal experience > that the performance and throughput gains were huge. A message queue is a tier above sockets that provides specific services. It's not an either/or proposition. If you don't need message queuing, sure, you may be happy with a simple socket and the right protocol. If you do need message queuing, raw sockets will be far from adequate. > From: doug chanco > I am about to do some socket programming with the universe socket API > (universe 10.2.x and aix 5.3.x), are there any > gotchas/advice/suggestions anyone would care to share? Sockets by themselves have no protocol above TCP/IP and are only as stable as the protocol you create. Be careful of timing, allow for retrying bad transactions and dead connections. If you have any intent to use multiple sockets you're going to have to create a process manager, perhaps with multiple threads. Most people don't go this far. A full response to your inquiry really depends on the answer to another question, which is "why are you doing this?" Sockets are geeky, fun, and challenging, and quite satisfying when they work correctly, but for the most part working at that tier is hardly cost-effective given the plethora of software available to do communications at a higher level. Do you want to do sockets for fun or because your business requires communications? Are you trying to build a better mousetrap or trying to save money? You're going to spend a few weeks on this, now or over time. Is your time really worth less than the free tools from IBM, or commercial tools that only cost a couple hundred bucks? Also, if you decide to change employers (or your clients change vendors), who is going to get stuck maintaining all of the custom code? If I were an IT director I would not allow someone to write a custom socket interface internally for production use. I have the same issue with FOSS projects that are unmaintained - they're more of a liability than an asset if the code is unmaintainable. On the other hand, there are few good _and_ cost-effective comms solutions entirely based on *nix for use with MV. I think this is a major hole in our market. If someone created a low-cost, cross-MV tool that facilitated fast and stable comms, with session pooling, caching, and other middle-tier services, for example through Mod-Apache or Tomcat into MV, I'd take a close look at that rather than writing custom socket interfaces into every MV platform. HTH Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
