Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 2 Apr 2010 13:09 "Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message news:OCiGrPo0KHA.224(a)TK2MSFTNGP06.phx.gbl... > > "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in > message news:fg5cr5durc5vv2mk649328v1qs9i0inuqu(a)4ax.com... > > Joe... the responses by Hector on April 1st appear to be > jokes... :-) > > -Pete > Including the one where the venture capitalist gives you back the 97% ownership that they took?
From: Joseph M. Newcomer on 2 Apr 2010 13:51 See below... On Thu, 01 Apr 2010 15:10:53 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: > >Windows doesn't support Named Pipes! **** What does the CreateNamedPipe API do? Windows doesn't support "named pipes" that look like linux "named pipes"; it is a confusion of using the same term to described two completely different ideas. 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 2 Apr 2010 15:05 See below... On Fri, 2 Apr 2010 12:08:21 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:fg5cr5durc5vv2mk649328v1qs9i0inuqu(a)4ax.com... >> See below... >> On Thu, 01 Apr 2010 15:04:12 -0400, Hector Santos >> <sant9442(a)nospam.gmail.com> wrote: >> >>> >>>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. >> **** >> Actually, nobody answered because the question was >> essentially silly. Anyone who receives >> email knows that it isn't very reliable. > >What about FTP? I could do my on-the-fly backup using FTP. *** OK, and you have now introduced another complex mechanism into the validation of the state diagram. How is it that FTP increases the reliability without introducing what I might call "gratuitous complexity". Note that your state diagram now has to include the entire FTP state diagram as a subcomponent. Have you looked at the FTP state diagram? Especially for the new, restartable, FTP protocols? joe **** > >>>Do you won't offer a federal required return policy? But >>>you will >>>never have that problem >> **** >> Note that if I receive a package, which is left on my >> porch, and someone steals it, then I >> have not "received" it. And I'm not going to pay for it. >> And I WILL demand a refund on >> my credit card. The reasons FedEx and UPS don't REQUIRE >> "live signatures" any longer is >> that they have learned that the probability of theft is >> nearly zero, the insurance >> reimburses the sender, who then reimburses me, and paying >> for the occaasional loss is >> cheaper than the cost of getting live signatures for every >> delivery. And some shipments >> have MANDATORY "live signature" requirements [e.g., my new >> Dell computer that arrived last >> week], and if there is a history of packages being stolen >> from a particular address [e.g., >> the recipient is committing fraud, or the packages are >> really being stolen] or thefts to a >> particular neighborhood, the transporter will impose >> MANDATORY "live signature" >> requirements on the delivery. > >I will sent the results waiting for an HTTP acknowledgement, >and only deduct the dime from the account balance if I get >an HTTP acknowledgement. These same results will be >available for at least thirty days whenever a client logs >in. The client request optional email delivery too. This >seems sufficient to me, did I miss anything? **** I think you have introduced at lot of gratuitous complexity here; instead, discard the whole transaction, credit the end user, and let them resubmit if they need to. Simple. **** > >> >> Bottom line: you can't use your excuse on real >> transactions. The excuses don't have any >> legal basis. Have fun! >> **** >>> >>>>> 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! >> **** >> Sorry, My ISP acknowledges receipt, and their anti-spam >> throws the message away and they >> don't send it to me, I have not received it. End of >> story. You seem to have missed this >> point. In networking terms, "reliable" has a different >> meaning than the intuitive one. A > >That always screws me up. > >> mechanism that reports errors IS considered "100% >> reliable" (e.g., TCP/IP) whereas one >> that does not report errors is considered UNRELIABLE >> (e.g., UDP). So when my ISP accepts >> the message, they "reliably" acknowledge that they have >> received it. Or, if they >> determine it is spam, they fail to acknowledge that they >> have received it. But the >> antivirus algorithm runs AFTER receipt is acknowledged and >> may yet throw it away. >> >> You have failed to understand what is meant by >> "reliability" and you have made a naive >> assumption that ACK==DELIVERY. In Real Life, the systems >> do not work according to your >> fantasies, and therefore predicating a business plan on >> fantasies boils down to, in its >> essence, failure. > >So what about FTP? **** Gratuitous complexiyt. **** > >> >> Also, look into ORBIS (I think that's how the acronym is >> spelled); my ISP is an ORBIS >> member, and one of my correspondents goes through a >> non-ORBIS carrier, and I get about 1 >> out of 10 messages he sends me. If he sends from another >> of his email accounts, I get 10 >> of 10 from that account, because it routes through ORBIS >> members. ORBIS is an informal >> anti-spam consortium who simply drop any email that comes >> from known spam routers. >> Apparently the way this is handled to is "acknowledge" it >> and throw it away. >> >> But a belief that there is a "100% verifiable" mechanism >> relies on definitions of the word >> "verifiable" that are, at best, creative, and an >> interpretation of probability that goes >> beyond the formal definition of "Expected value" that >> every statistics book takes great >> care to explain. So I'm not sure what you are asking for, >> but I'm pretty sure your >> expectations are fantasy. >> >> **** >>> >>>>> 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 >> **** >> But TCP/IP ALWAYS has a dropped-connection detection! >> That's one of its design >> requirementments...of course, you actually have to LOOK >> for the event! >> joe > >So great then this will be my primary basis. Some customers >might prefer some sort of batch oriented automated delivery. >Email seemed to be the obvious choice. I have never had the >degree of difficulty that you have stated as possible. I >even bought several software packages where the means of >delivery was an emailed link. **** Simple, obvious and wrong... Note that if I don't receive the email, I get to contact them again. Expect this will happen to you. *** > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 2 Apr 2010 15:32 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:cnfcr5t8ht5v51r2b80un0jjcas396bmcs(a)4ax.com... > See below... > On Fri, 2 Apr 2010 12:08:21 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:fg5cr5durc5vv2mk649328v1qs9i0inuqu(a)4ax.com... >>> See below... >>> On Thu, 01 Apr 2010 15:04:12 -0400, Hector Santos >>> <sant9442(a)nospam.gmail.com> wrote: >>> >>>> >>>>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. >>> **** >>> Actually, nobody answered because the question was >>> essentially silly. Anyone who receives >>> email knows that it isn't very reliable. >> >>What about FTP? I could do my on-the-fly backup using FTP. > *** > OK, and you have now introduced another complex mechanism > into the validation of the state > diagram. How is it that FTP increases the reliability > without introducing what I might > call "gratuitous complexity". Note that your state > diagram now has to include the entire > FTP state diagram as a subcomponent. Have you looked at > the FTP state diagram? Especially > for the new, restartable, FTP protocols? > joe Yeah right the whole thing is so complex that no one could every possibly accomplish it so I might as well give up, right? I ALWAYS determine feasibility BEFORE proceeding with any further analysis. If FTP is not reliable, then I am done considering FTP. If FTP is reliable then it might possibly form a way for transaction by transaction offsite backup. It seems that you investigate all of the little nuances of every detail before even considering feasibly. That is not very efficient is it? > **** >> >>>>Do you won't offer a federal required return policy? But >>>>you will >>>>never have that problem >>> **** >>> Note that if I receive a package, which is left on my >>> porch, and someone steals it, then I >>> have not "received" it. And I'm not going to pay for >>> it. >>> And I WILL demand a refund on >>> my credit card. The reasons FedEx and UPS don't REQUIRE >>> "live signatures" any longer is >>> that they have learned that the probability of theft is >>> nearly zero, the insurance >>> reimburses the sender, who then reimburses me, and >>> paying >>> for the occaasional loss is >>> cheaper than the cost of getting live signatures for >>> every >>> delivery. And some shipments >>> have MANDATORY "live signature" requirements [e.g., my >>> new >>> Dell computer that arrived last >>> week], and if there is a history of packages being >>> stolen >>> from a particular address [e.g., >>> the recipient is committing fraud, or the packages are >>> really being stolen] or thefts to a >>> particular neighborhood, the transporter will impose >>> MANDATORY "live signature" >>> requirements on the delivery. >> >>I will sent the results waiting for an HTTP >>acknowledgement, >>and only deduct the dime from the account balance if I get >>an HTTP acknowledgement. These same results will be >>available for at least thirty days whenever a client logs >>in. The client request optional email delivery too. This >>seems sufficient to me, did I miss anything? > **** > I think you have introduced at lot of gratuitous > complexity here; instead, discard the > whole transaction, credit the end user, and let them > resubmit if they need to. Simple. > **** >> >>> >>> Bottom line: you can't use your excuse on real >>> transactions. The excuses don't have any >>> legal basis. Have fun! >>> **** >>>> >>>>>> 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! >>> **** >>> Sorry, My ISP acknowledges receipt, and their anti-spam >>> throws the message away and they >>> don't send it to me, I have not received it. End of >>> story. You seem to have missed this >>> point. In networking terms, "reliable" has a different >>> meaning than the intuitive one. A >> >>That always screws me up. >> >>> mechanism that reports errors IS considered "100% >>> reliable" (e.g., TCP/IP) whereas one >>> that does not report errors is considered UNRELIABLE >>> (e.g., UDP). So when my ISP accepts >>> the message, they "reliably" acknowledge that they have >>> received it. Or, if they >>> determine it is spam, they fail to acknowledge that they >>> have received it. But the >>> antivirus algorithm runs AFTER receipt is acknowledged >>> and >>> may yet throw it away. >>> >>> You have failed to understand what is meant by >>> "reliability" and you have made a naive >>> assumption that ACK==DELIVERY. In Real Life, the >>> systems >>> do not work according to your >>> fantasies, and therefore predicating a business plan on >>> fantasies boils down to, in its >>> essence, failure. >> >>So what about FTP? > **** > Gratuitous complexiyt. > **** > >> >>> >>> Also, look into ORBIS (I think that's how the acronym is >>> spelled); my ISP is an ORBIS >>> member, and one of my correspondents goes through a >>> non-ORBIS carrier, and I get about 1 >>> out of 10 messages he sends me. If he sends from >>> another >>> of his email accounts, I get 10 >>> of 10 from that account, because it routes through ORBIS >>> members. ORBIS is an informal >>> anti-spam consortium who simply drop any email that >>> comes >>> from known spam routers. >>> Apparently the way this is handled to is "acknowledge" >>> it >>> and throw it away. >>> >>> But a belief that there is a "100% verifiable" mechanism >>> relies on definitions of the word >>> "verifiable" that are, at best, creative, and an >>> interpretation of probability that goes >>> beyond the formal definition of "Expected value" that >>> every statistics book takes great >>> care to explain. So I'm not sure what you are asking >>> for, >>> but I'm pretty sure your >>> expectations are fantasy. >>> >>> **** >>>> >>>>>> 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 >>> **** >>> But TCP/IP ALWAYS has a dropped-connection detection! >>> That's one of its design >>> requirementments...of course, you actually have to LOOK >>> for the event! >>> joe >> >>So great then this will be my primary basis. Some >>customers >>might prefer some sort of batch oriented automated >>delivery. >>Email seemed to be the obvious choice. I have never had >>the >>degree of difficulty that you have stated as possible. I >>even bought several software packages where the means of >>delivery was an emailed link. > **** > Simple, obvious and wrong... > > Note that if I don't receive the email, I get to contact > them again. > > Expect this will happen to you. > *** >> > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 2 Apr 2010 15:44
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:1lbcr5lo46hg8ha34t4rmeb5v731i7f14l(a)4ax.com... > See below... > On Fri, 2 Apr 2010 11:44:43 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: >>OK I think that I have it. If the customer account >>balances >>are stored in a file (binary data, fixed length records, >>thus easy to seek to), then we would probably need a >>record >>lock on the client's record that remains in effect between >>reading the current balance, and writing the updated >>balance. > **** > You are violating your rule of dropping to the physic'al > level without knowing that the > abstract requirements are being met. > For example, the presumption that "atomic append" > meets the requirements or that a binary file even matters > in this discussion seem both > unjustified assumptions. Because the record lock idea would ensure one significant aspect of transactional integrity, and your mind is stuck in "refute mode" you had to square peg in round hole with hammer another aspect of what I said. > **** >> >>As far as the specific detail of updating the client's >>balance (abstracting from our attention the details >>required >>to determine exactly when this should and should not be >>done) this would seem to be sufficient. > **** > The specific detail here is the ONLY thing that matters. > Once you have set the > requirements, and built the state transition diagram, you > have to demonstrate that > snipping any state transition still leaves the overall > transaction in a known state. There > is no guarantee the "pwrite" commits the data to the disk, > for example, so mentioning it > as an implementation strategy creates a warm fuzzy feeling > of "the problem is solved" > without any evidence tha the problem is actually solved! > **** >> >>If we only do this at the very end of processing after the >>HTTP client has specifically acknowledged receipt of the >>data, then this transaction should also never need to be >>automatically rolled back. The customer may ask for a >>refund, but, this is a whole other different issue. > **** > Read my description of creating and validating the state > diagram; you have to go whereever > that leads you > **** >> >>Do you see any holes in the above reasoning? > **** > As I pointed out, the design is really Swiss Cheese in > terms of holes. You do not have a > completed, robust, state machine nor a way of validating > that any cut-point results in an > acceptable state (a valid state or a state from which > valid recovery can be made). Until > that is done, you do not have a specification, you have a > requirements document. > Requirements documents are good, but they do not guarantee > that an implementation can or > will exist that meets them. > > Once you have the specification document, you can worry > about whether or not pwrite > ACTUALLY causes a commit to disk, or just appends > logically to the copy of the file > maintained in RAM without actually comitting those changes > to the hard drive, which is a > mere implmenetation detail once you have validated the > specification. > joe > **** >> > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |