Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 1 Apr 2010 13:50 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:4ff9r5ltn625v5977frmcq84984n1iklga(a)4ax.com... > See below... > On Wed, 31 Mar 2010 10:58:24 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >>If the only thing that I must insure does not occur is >>that >>the customer is not charged for a transaction that did not >>complete, this simplifies the design. > **** > And a belieft that email is reliable (in spite of the > overwhelming evidence that it is > not) solves this how? I asked if email at least had verifiable reliability and no one answered. I could do on-the-fly off-site backups of every transaction by email. > Better to simply credit the account and drop the > transaction. If > they want it, they'll submit again, knowing the > uncompleted transaction had been credited > to their account. I don't know maybe. I will await the critique of my current much more refined IPC design. It still may be full of holes, but, the holes would be much smaller now. > > Never mind, I just answered how: a "belief" is good > enough, facts don't actually matter. > **** >>For every complex set >>of issues there is always a way to minimize the effective >>complexity. > **** > "For any problem, there is a solution that is simple, > obvious, and wrong". > -- H.L. Mencken > **** >> >>One thing that I need to know hopefully without the need >>to >>read a 1,000 page book first, Is there any way that the >>sender of an email message can automatically confirm that >>an >>email was received. This is one of the questions that I >>know >>needs to be answered and if no one else is helpful on this >>I >>will eventually find it elsewhere. > **** > Did you read Hector's message explaining email > acknowledgements? Turns out that an > acknowledgement of receipt has value to spammers, which is > why an ISP is now permitted to > acknowledge receipt and discard the message, at any stage > along the way. I put Hector on the blocker sender list for a while. His rudeness went beyond a tolerable threshold. So your comment is vague. Are all emails acknowledged as received or not? >> >>If email has precisely measurable reliability, then on the >>fly backups of transaction details can be made. > **** > Outlook has a feature to acknowledge to the sender when an > email is read, and the first > thing any intelligent person does is turn off the feature > that says "inform the sender > when I have read this message". We call it "invasion of > privacy" I am not talking about whether they read it or not. I am not concerned with that. If they pay me some money to ship a package and the package arrives, then my obligation is done, even if they never open the package. > > I have no idea what you mean by "precisely measurable > reliability" Is there any sort of hand-shaking protocol such that all emails are explicitly acknowledged as received by the receiving ISP? Even if email itself is very unreliable, as long as it always reports its own failure to deliver, then we have one aspect of precisely measurable reliability. > and what this has to do > with anything real. For example, suppose I told you "I > have precisely measured the > reliability, and the probability your message is actually > received is 0.48�0.02. That is > *precise* but it does not solve your problem, because it > says that there is less than a > 50% probability that your email will be received. You > have apparently confused "precisely > measurable" with "100% probability". And notice 100% > probability is not the same as > saying there can be no failure (if you don't believe this, > a remedial course in statistics > would be necessary). > > To me, the only reliable mechanism is to drop the > transaction, but credit the account. The > belief that there is a reliable "callback" mechanism is > ill-founded and I would not use > anything that was not completely guaranteed to be correct. > Crediting the account can be > made completely reliable, as long as you are using a > transacted database to record the > transactions you are charging for (this is why transacted > databases were created!) > **** I don't know maybe. Since all users will also have the results of their transaction posted to their user account, and I won't know that the connection is dropped until the most expensive part of the processing is completed, I might not do it this way. The nest time that the user logs in, I would inform them of these results, and provide a link to get these results. If the connection is dropped, they would have to log in again to try to repeat the original transaction. >> >>> Corollary: this system will be such a finacial success >>> (at >>> $0.10/transaction) that he will >>> soon have unlimited funds to hire people to solve all >>> the >>> very real problems he has been >>> ignoring. [He even said so!] >> >>It is not a matter of counting my chickens before they >>hatch, it is a matter of simple arithmetic. The minimal >>system will be able to handle at least 10 transactions per >>second. (With the redesign it is looking more like 100 per >>second now). I will have to have sufficient load on my >>system before upgrading it is justified. There is no sense >>upgrading a system for much better performance if peak >>load >>it is only at 1% of capacity. This 1% of capacity produces >>a >>dime a second. Even an huge degree of difference between >>peak load and average load should not change this overall >>evaluation much. Whenever I do need to upgrade beyond a >>single core processor, I will be able to afford it, and it >>looks like a long time before I will need to upgrade. > **** > I can handle X number of transactions per second, and > therefore people will actually > engage in enough of a percentage of X number of > transactions per second to generate > significant revenue. > > Capacity is not utilization. > > If I build a grocery store, put 22 checkout lanes in it, > populate them with 22 cashiers, I > will not survive if the average purchase is $2.00 each > from 40 customers a day. > > I've had business plans I worked on (and I was not the > principal of the company) turned > down because the plan did not demonstrate that the > expected income could be realized. As > a sanity check, get a real financial expert to review the > business plan for feasibility. > They will ask some important questions, and handwaves will > not suffice for answers. In > fact, I believe that the banks and venture capitalists > were justified in turning down our > business proposals because those proposals were weak in > how the technology would be turned > into revenue. In later years, we got better at writing > proposals. Then both of us > decided we no longer had the energy to do a startup (by > the time you hit 55, the ability > to pull 80-hour weeks decreases, as does the motivation. > If you look at your finances and > say "I could retire, comfortably, now, or I could do a > startup" the choice gets easy after > age 55. It doesn't mean I haven't learned a lot in trying > to do thos startups between age > 35 and 55. We would come up with a new idea every 2-3 > years. > ***** >> >>> >>> One thing I learned being self-employed: every expense >>> turns out to be expressible >>> precisely in hours of my time. So to hire me for 1 hour >>> will require 1,000 transactions. >>> And I'm cheap (I've been told I consistently underprice >>> myself). A full-time person >>> requires about 2,500 transactions for every hour they >>> work, so to support a full-time >>> person requires 1370 transactions every day, 57 >>> transactions/hour EVERY HOUR OF EVERY DAY >>> just to break even. That's a little under 1/minute >> >>Right and the cheap single core processor can do 100 per >>second, so there is a much greater chance that I would >>hire >>you or someone else than there is that I would need to >>upgrade beyond a single core, thus all this talk about >>multiple threads or multiple processes is not really >>cost-effective for me right now. > **** > I'm glad that you know that. It is important to know > cost-effectiveness of solutions. > joe > **** >> > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 1 Apr 2010 14:27 See below... On Thu, 1 Apr 2010 12:50:02 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:4ff9r5ltn625v5977frmcq84984n1iklga(a)4ax.com... >> See below... >> On Wed, 31 Mar 2010 10:58:24 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> > >>>If the only thing that I must insure does not occur is >>>that >>>the customer is not charged for a transaction that did not >>>complete, this simplifies the design. >> **** >> And a belieft that email is reliable (in spite of the >> overwhelming evidence that it is >> not) solves this how? > >I asked if email at least had verifiable reliability and no >one answered. I could do on-the-fly off-site backups of >every transaction by email. **** The reason no one answered is there IS no "verified reliability", in fact, the only thing we CAN verify is that it is NOT reliable! > >> Better to simply credit the account and drop the >> transaction. If >> they want it, they'll submit again, knowing the >> uncompleted transaction had been credited >> to their account. > >I don't know maybe. I will await the critique of my current >much more refined IPC design. It still may be full of holes, >but, the holes would be much smaller now. **** I've not see the "refined" IPC design, so I cannot ocmment on it. *** > >> >> Never mind, I just answered how: a "belief" is good >> enough, facts don't actually matter. >> **** >>>For every complex set >>>of issues there is always a way to minimize the effective >>>complexity. >> **** >> "For any problem, there is a solution that is simple, >> obvious, and wrong". >> -- H.L. Mencken >> **** >>> >>>One thing that I need to know hopefully without the need >>>to >>>read a 1,000 page book first, Is there any way that the >>>sender of an email message can automatically confirm that >>>an >>>email was received. This is one of the questions that I >>>know >>>needs to be answered and if no one else is helpful on this >>>I >>>will eventually find it elsewhere. >> **** >> Did you read Hector's message explaining email >> acknowledgements? Turns out that an >> acknowledgement of receipt has value to spammers, which is >> why an ISP is now permitted to >> acknowledge receipt and discard the message, at any stage >> along the way. > >I put Hector on the blocker sender list for a while. His >rudeness went beyond a tolerable threshold. So your comment >is vague. Are all emails acknowledged as received or not? **** Sorry you missed his detailed reply. I see no reason to repeat it here. The truth is that some server feel free to send a positive acknowledgement before they apply anti-spam rules, so essentially any positive acknowledgement merely states that somewhere along the line, SOMEBODY "received" it; whether or not it go DELIVERED is not specified! **** > >>> >>>If email has precisely measurable reliability, then on the >>>fly backups of transaction details can be made. >> **** >> Outlook has a feature to acknowledge to the sender when an >> email is read, and the first >> thing any intelligent person does is turn off the feature >> that says "inform the sender >> when I have read this message". We call it "invasion of >> privacy" > >I am not talking about whether they read it or not. I am not >concerned with that. If they pay me some money to ship a >package and the package arrives, then my obligation is done, >even if they never open the package. **** If I don't receive a package, I question the validity of the charge. The fact that the package was lost along the way is not my concern, nor is the allegation that you sent it matter in the slightest if I did not receive it. My receipt is the ONLY thing that matters, and you cannot guarantee that. **** > >> >> I have no idea what you mean by "precisely measurable >> reliability" > >Is there any sort of hand-shaking protocol such that all >emails are explicitly acknowledged as received by the >receiving ISP? Even if email itself is very unreliable, as >long as it always reports its own failure to deliver, then >we have one aspect of precisely measurable reliability. *** Read Hector's reply. I'm sure you can find it in the archives. It was very detailed. From a network perspective, email is an "unreliable" transport mechanism. **** > >> and what this has to do >> with anything real. For example, suppose I told you "I >> have precisely measured the >> reliability, and the probability your message is actually >> received is 0.48�0.02. That is >> *precise* but it does not solve your problem, because it >> says that there is less than a >> 50% probability that your email will be received. You >> have apparently confused "precisely >> measurable" with "100% probability". And notice 100% >> probability is not the same as >> saying there can be no failure (if you don't believe this, >> a remedial course in statistics >> would be necessary). >> >> To me, the only reliable mechanism is to drop the >> transaction, but credit the account. The >> belief that there is a reliable "callback" mechanism is >> ill-founded and I would not use >> anything that was not completely guaranteed to be correct. >> Crediting the account can be >> made completely reliable, as long as you are using a >> transacted database to record the >> transactions you are charging for (this is why transacted >> databases were created!) >> **** > >I don't know maybe. Since all users will also have the >results of their transaction posted to their user account, >and I won't know that the connection is dropped until the >most expensive part of the processing is completed, I might >not do it this way. The nest time that the user logs in, I >would inform them of these results, and provide a link to >get these results. If the connection is dropped, they would >have to log in again to try to repeat the original >transaction. **** This is a possible approach, as long as you can guarantee that this cannot fail. joe *** > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Liviu on 1 Apr 2010 14:35 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote... > On Wed, 31 Mar 2010 22:56:59 -0500, "Liviu" <lab2k1(a)gmail.c0m> wrote: >>"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >>> >>> If you read much of the patent you would see that this is not the >>> case. >> >>Oh, right... There is also the "store a DFA as a sparse matrix" thing. > **** > Back in 1982, I implemented a new kind of sparse matrix approach, > "comb vectors", based on a research paper from the University of > Karlsruhe, Karlsruhe, Germany, which outlined the algorithm. I'm not > sure if Gerhod Goos was one of the authors or it was a set of his > students; I no longer have the paper. But it "interlaces" the "holes" > in a parse-table vector so that we got incredible density in the > immense parse tables. I still have the code, but cannot release it. > So recompaction of spare matrices was an idea that was well-understood > in 1981 or so. Sure was. I (used to) know a thing or two about sparse matrices back in the early 80's, having done some research which involved resultants of sparse polynomials. It was also obvious at the time that the more one knew about particular "sparseness" characteristics of the matrix, the more dramatic "compaction" could be achieved. Unrelated (and this is no stab at P.O.) but the patent language in general amuses me to no end with "de rigueur" convolutions like... || The term "Sparse Matrix" is taken to have the common meaning || of the term "Sparse" combined with the common computer science || meaning of the term "Matrix", a two dimensional array of elements. > So it opens the issue about prior art on some of the compaction; > I have not read the patent details soo I don't know if the compaction > model differs from what I know to be past history, but I do know > that DFA compaction is still patentable I never disputed that point. As for his patent, on cursory reading it's a combination between a fast DFA "exact pixel matching" recognition (compare to: face tagging in photos, 100% accurate if one has a prior database of the face at all sizes, angles, expressions, lighting etc) and an idea that it could be somehow used for "remote control" of another system (compare to: character-mode screen scraping and keyboard control over a terminal session into a mainframe). I did not mean to, and not going to, argue the merits, or the prior art doubts. The point I tried to make a few times (too many) was that without a viable implementation and/or business plan, the best of patents will forever remain just a piece of paper to frame and hang on the wall. Liviu
From: Peter Olcott on 1 Apr 2010 14:58 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:m0p9r5hovngicdjqipdojt9kkvt55sq9mo(a)4ax.com... > > See below... > On Thu, 1 Apr 2010 12:50:02 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:4ff9r5ltn625v5977frmcq84984n1iklga(a)4ax.com... >>> See below... >>> On Wed, 31 Mar 2010 10:58:24 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >> >>>>If the only thing that I must insure does not occur is >>>>that >>>>the customer is not charged for a transaction that did >>>>not >>>>complete, this simplifies the design. >>> **** >>> And a belieft that email is reliable (in spite of the >>> overwhelming evidence that it is >>> not) solves this how? >> >>I asked if email at least had verifiable reliability and >>no >>one answered. I could do on-the-fly off-site backups of >>every transaction by email. > **** > The reason no one answered is there IS no "verified > reliability", in fact, the only thing > we CAN verify is that it is NOT reliable! >> >>> Better to simply credit the account and drop the >>> transaction. If >>> they want it, they'll submit again, knowing the >>> uncompleted transaction had been credited >>> to their account. >> >>I don't know maybe. I will await the critique of my >>current >>much more refined IPC design. It still may be full of >>holes, >>but, the holes would be much smaller now. > **** > I've not see the "refined" IPC design, so I cannot ocmment > on it. > *** >> >>> >>> Never mind, I just answered how: a "belief" is good >>> enough, facts don't actually matter. >>> **** >>>>For every complex set >>>>of issues there is always a way to minimize the >>>>effective >>>>complexity. >>> **** >>> "For any problem, there is a solution that is simple, >>> obvious, and wrong". >>> -- H.L. Mencken >>> **** >>>> >>>>One thing that I need to know hopefully without the need >>>>to >>>>read a 1,000 page book first, Is there any way that the >>>>sender of an email message can automatically confirm >>>>that >>>>an >>>>email was received. This is one of the questions that I >>>>know >>>>needs to be answered and if no one else is helpful on >>>>this >>>>I >>>>will eventually find it elsewhere. >>> **** >>> Did you read Hector's message explaining email >>> acknowledgements? Turns out that an >>> acknowledgement of receipt has value to spammers, which >>> is >>> why an ISP is now permitted to >>> acknowledge receipt and discard the message, at any >>> stage >>> along the way. >> >>I put Hector on the blocker sender list for a while. His >>rudeness went beyond a tolerable threshold. So your >>comment >>is vague. Are all emails acknowledged as received or not? > **** > Sorry you missed his detailed reply. I see no reason to > repeat it here. The truth is > that some server feel free to send a positive > acknowledgement before they apply anti-spam > rules, so essentially any positive acknowledgement merely > states that somewhere along the > line, SOMEBODY "received" it; whether or not it go > DELIVERED is not specified! > **** >> >>>> >>>>If email has precisely measurable reliability, then on >>>>the >>>>fly backups of transaction details can be made. >>> **** >>> Outlook has a feature to acknowledge to the sender when >>> an >>> email is read, and the first >>> thing any intelligent person does is turn off the >>> feature >>> that says "inform the sender >>> when I have read this message". We call it "invasion of >>> privacy" >> >>I am not talking about whether they read it or not. I am >>not >>concerned with that. If they pay me some money to ship a >>package and the package arrives, then my obligation is >>done, >>even if they never open the package. > **** > If I don't receive a package, I question the validity of > the charge. The fact that the > package was lost along the way is not my concern, nor is > the allegation that you sent it > matter in the slightest if I did not receive it. My > receipt is the ONLY thing that > matters, and you cannot guarantee that. > **** >> >>> >>> I have no idea what you mean by "precisely measurable >>> reliability" >> >>Is there any sort of hand-shaking protocol such that all >>emails are explicitly acknowledged as received by the >>receiving ISP? Even if email itself is very unreliable, as >>long as it always reports its own failure to deliver, then >>we have one aspect of precisely measurable reliability. > *** > Read Hector's reply. I'm sure you can find it in the > archives. It was very detailed. > > From a network perspective, email is an "unreliable" > transport mechanism. > > **** >> >>> and what this has to do >>> with anything real. For example, suppose I told you "I >>> have precisely measured the >>> reliability, and the probability your message is >>> actually >>> received is 0.48�0.02. That is >>> *precise* but it does not solve your problem, because it >>> says that there is less than a >>> 50% probability that your email will be received. You >>> have apparently confused "precisely >>> measurable" with "100% probability". And notice 100% >>> probability is not the same as >>> saying there can be no failure (if you don't believe >>> this, >>> a remedial course in statistics >>> would be necessary). >>> >>> To me, the only reliable mechanism is to drop the >>> transaction, but credit the account. The >>> belief that there is a reliable "callback" mechanism is >>> ill-founded and I would not use >>> anything that was not completely guaranteed to be >>> correct. >>> Crediting the account can be >>> made completely reliable, as long as you are using a >>> transacted database to record the >>> transactions you are charging for (this is why >>> transacted >>> databases were created!) >>> **** >> >>I don't know maybe. Since all users will also have the >>results of their transaction posted to their user account, >>and I won't know that the connection is dropped until the >>most expensive part of the processing is completed, I >>might >>not do it this way. The nest time that the user logs in, I >>would inform them of these results, and provide a link to >>get these results. If the connection is dropped, they >>would >>have to log in again to try to repeat the original >>transaction. > **** > This is a possible approach, as long as you can guarantee > that this cannot fail. > joe > *** That mostly depends upon the quality of my IPC design. I posted this in the Unix/Linux/Threads groups because this design depends on features of the Unix/Linux OS. Basically it has two named pipes that form the FIFO Queue, and both of these coordinate through a single binary file with fixed length records, that forms the transaction log. It requires two named pipes one for each direction of communication. The web server uses one pipe provide transactions to the OCR process. The OCR process uses the other pipe to inform the web server that one transaction has been processed. As soon as a web request is made it is written to the log file, and then to the FIFO Queue connected to the OCR process. The OCR process then updates the transaction log status to [Being Processed]. The log file keeps track of all of the transaction details, and has three flags: 0=Available for Processing 1=Being Processed 2=Processing is Completed As soon as a web request has completed processing, the transaction log status is updated to [Processing is Completed], and a message is written to the FIFO Queue connected to the web server. Unix/Linux guarantees that appends to files is an atomic operation, and provides pread() and pwrite() that perform a seek and then a read or write as a single atomic operation. The log file is the persistent storage and serves many purposes. >> > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 1 Apr 2010 15:04
Peter Olcott wrote: >> And a belieft that email is reliable (in spite of the >> overwhelming evidence that it is >> not) solves this how? > > I asked if email at least had verifiable reliability and no > one answered. Thats because you were not listening again. > I put Hector on the blocker sender list for a while. His > rudeness went beyond a tolerable threshold. So your comment > is vague. Joe thinks you are STUPID too! If fact, I wouldn't be off base the whole group knows you are stupid! > Are all emails acknowledged as received or not? YES all of them. Email is always accepted. You can rest assured in your patent, trade secrets and business plan, that you can guarantee a fault tolerance email contact system with your customers so that you don't have to give refunds in your fictitious wish list product line. >> **** >> Outlook has a feature to acknowledge to the sender when an >> email is read, and the first >> thing any intelligent person does is turn off the feature >> that says "inform the sender >> when I have read this message". We call it "invasion of >> privacy" > > I am not talking about whether they read it or not. I am not > concerned with that. If they pay me some money to ship a > package and the package arrives, then my obligation is done, > even if they never open the package. Do you won't offer a federal required return policy? But you will never have that problem >> I have no idea what you mean by "precisely measurable >> reliability" > > Is there any sort of hand-shaking protocol such that all > emails are explicitly acknowledged as received by the > receiving ISP? Even if email itself is very unreliable, as > long as it always reports its own failure to deliver, then > we have one aspect of precisely measurable reliability. No such thing - PATENT IT! >> To me, the only reliable mechanism is to drop the >> transaction, but credit the account. The >> belief that there is a reliable "callback" mechanism is >> ill-founded and I would not use >> anything that was not completely guaranteed to be correct. >> Crediting the account can be >> made completely reliable, as long as you are using a >> transacted database to record the >> transactions you are charging for (this is why transacted >> databases were created!) >> **** > I don't know maybe. Since all users will also have the > results of their transaction posted to their user account, > and I won't know that the connection is dropped until the > most expensive part of the processing is completed, HA! No drop connection detection I might > not do it this way. The nest time that the user logs in, I > would inform them of these results, and provide a link to > get these results. If the connection is dropped, they would > have to log in again to try to repeat the original > transaction. That will work! Your prices will include surcharge for Peter errors! -- HLS |