From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?B?QmrDtnJuIEx1bmRpbg==?= Newsgroups: comp.lang.ada Subject: Re: =?UTF-8?B?R05BVMKgYW5kIFRhc2tsZXRz?= Date: Fri, 19 Dec 2014 12:56:56 +0100 Organization: A noiseless patient Spider Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 19 Dec 2014 11:56:39 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="f6df73911ff23addd22916dd4a43b2a5"; logging-data="21738"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LGqa+9a0NtcJkR4HQWlsh" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 In-Reply-To: Cancel-Lock: sha1:MykdNal0f4tzHqvsHJTGsWgl+8Q= Xref: news.eternal-september.org comp.lang.ada:24144 Date: 2014-12-19T12:56:56+01:00 List-Id: On 2014-12-19 00:01, Randy Brukardt wrote: > For something like sockets, which are relatively slow compared to the > computer, polling has no visible effect on performance and ensures that > nothing will get starved. > > If you're using a high-level communication library (not some low-level > sockets bindings - yuck!), how that's implemented is invisible to the > client. They shouldn't care. Well, it is the yuck alternative. A homebrew binding from 1996 with far to much exposed in the spec, making change difficult. To much backwards incompability. It resembles a bad version of AdaSockets. >> >> No. The reason is to have communication logic for say a >> crane or conveyor system in one process, and the business logic >> for that mechanical device in another process. >> (I'm talking about a warehouse control system here, >> with 20-50 daemon processes) > > That sounds confused to me. One would expect a communication abstraction > that all the business logic calls as needed. No. you want to separate the business logic from the actual protocol. You do it with libraries, but this design uses a set of specialized processes with IPC via names pipes. So the I/O process gets commands from business process. the I/O process then converts these commands to the actual protocall, and is responisible for securing data until acked. By this design, just change the I/O is fairly easy and maintainable business-process <-IPC-> I/O <-whatever proto-> PLC The internal IPC proctocol does not change. The busines process does not care about socket/serial/usb/ its the isolated I/O process' responsibility Change I/O process, and you are done with protocol-to-plc upgrade >How that abstraction is > organized should not be visible to the business logic at all. and it is not as per above > But we're getting way off-topic here, you're not going to redesign your > application because I think it sounds confused correct, let's leave it here. > I still think this sounds way too low-level. I/O in our industry _is_ low-level. > But I hope you're using a nice Ada abstraction of sockets and not > just calling raw C routines to do stuff. (If you are, you're hopeless and > this whole discussion is irrelevant.) So, just let us call me hopeless. However, I do know about Murphy's law "if it _can_ happen it _will_ happen" This design runs at site with 50_000 + tote movements per day, and has for many years. A tote move will need say 10 messages back-and forth in cranes and conveyors for going out from store and back in again. This gives about half a million messages - a day - on a busy site. Murphy should have kicked in here long time ago. This design do work very well. > Right. And even on the systems where it worked, you're dependent that your > sockets library doesn't do any buffering (NC_Sockets can), doesn't have any > local data other than a sockets handle, and the like. A updated sockets > library might change that behavior. correct, but homebrew (yuck) also means full control. No buffering. -- Björn