What type of connection are you using ?
---------- Original Message ----------- From: Kevin Fishburne <kevinfishbu...@eightvirtues.com> To: gambas-user@lists.sourceforge.net Sent: Tue, 30 Aug 2011 05:31:52 -0400 Subject: Re: [Gambas-user] gb3: using string as stream for sequential write operations of arbitrary datatypes > On 08/30/2011 04:35 AM, Bruce Bruen wrote: > > On Tue, 2011-08-30 at 01:52 -0400, Kevin Fishburne wrote: > >> When a transaction isn't received and I need to resend it, I'd like > >> to > >> be able to refer to the transaction history and resend the data > >> (QueueOut[id].Data) without having to recalculate it, especially > >> since > >> the data may have changed during the timeout period. I don't see any > >> way > >> to store a completely arbitrary set of datatypes as a single > >> structure > >> property however. I could write them to a file, then read the file > >> into > >> a string and load it into a property of the array of structures, but > >> that's just crazy. > > Kevin, > > > > I can't give you an answer to the question you ask, mainly because I > > kept seeing bigger problems as I read your post. From what I glean, > > this is a classic TX->ACK situation and I think you are basing the code > > on some type of timeout rule, such that TX->?->TX. However, there are > > some problems with that model. Firstly, where did the failure occur? > > a) firstly, the transaction was never "sent" from end A (why? is > > immaterial. What is, is that end B will not have any possibility of > > processing the transaction or sending the ACK) > > b) second, the transaction was fully received by end B, but for some > > reason it never ACK'ed it > > b1) it did process the full transaction, but never sent the ACK > > b2) it did not process the transaction and never sent the ACK > > c) the transaction was fully received, processed and the ACK sent, but > > it was never received by end A. > > Since at the end of the timeout, end A has no knowledge of the state of > > end B simply retransmitting the same transaction is considered "bad > > design" in network theory. (I could lookup the references for you, but > > they are on rotting pieces of paper somewhere in a mouldy box in the > > garage, and...) > > > From memory, there are at least two well-formed models regarding these > > problems: > > i) any retransmission is marked as such. This puts a need on the server > > to audit any retransmission and either process it or ignore it. > > ii) any failed transmission is assumed to have been processed by end B > > and a reversal transaction is sent by end A before retrying the > > transaction. This means that end B must implement a "reversal" > > procedure, but puts the onus on end A to ensure that the transaction > > ONLY HAPPENS ONCE (not yelling, just emphasising). > > > > Disregarding your need to store the sent transaction for a moment, it > > might be wise of you to consider how these. > > All those are valid observations about sending and receiving with acks. > My implementation works even with repeated and unwanted resends of data > from multiple sources (DoS). It keeps the place of each transaction for > each player, authenticating each through either an IP or > username/password lookup, and not incrementing the associated > transaction queue pointer unless processed properly. Incoming > transactions are placed in the queue position that their ID dictates, > their ID provided by the incoming transaction data. This way > out-of-order packets are stored in the incoming transaction queue > without affecting the execution order of the queue. The trick is to > place ack sends, ack receives, and transaction retransmissions outside > the scope (don't store them) of the incoming and outgoing queues. Just > make them happen, and as long as the .Acknowledged property is > maintained everything will flow smoothly. > > Network programming like this is a hell of a thing, though. God help us > all... > > -- > Kevin Fishburne > Eight Virtues > www: http://sales.eightvirtues.com > e-mail: sa...@eightvirtues.com > phone: (770) 853-6271 > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user ------- End of Original Message ------- ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user