Re: [Twisted-Python] PB and unstable network
You mean a packet message used in the TCP? Or offer to implement ACK to PB? Maybe someone will point to the literature on network programming in unstable networks? On Tue, May 25, 2010 at 6:41 PM, Yaroslav Fedevych wrote: > In your case, I would suggest that the server sends some sort of ACK > after it has received the payload from client, and the client must > send the same kind of ACK in response. Only after that would the > server consider operation complete, otherwise it would either inform > the client that the previous operation was interrupted midway, or > discard the incomplete message completely, thus forcing client to > re-send it. > > Sounds complicated, but I think that's the only reliable way to make > sure things don't get duplicated on either server or client. > > On Tue, May 25, 2010 at 11:34 AM, Viktor Klimov wrote: >> Hi Glyph, sorry for my english. >> >> My server.py save last answer(see User.perspectiveMessageReceived). >> >> Client when an error occurs(in callRemote) schedule reconnect. After >> reconnect client call remote method which return last answer. >> >> It works if disconnect happened when server send data to >> client(_server->client_). (try set MyServer.crash_server_to_client to >> True) >> >> But it doesn't work if disconnect happened when client send data to >> server(_client->server_). Becouse server after reconnect send previous >> data. It can fix if client be known when error occurs(server->client >> or client->server). (see comment in Client.net_error). >> >> PS for emulate error client->server set Client.crash_client_to_server >> to True, don't forget set MyServer.crash_server_to_client to False) >> >> On Mon, May 24, 2010 at 5:19 AM, Glyph Lefkowitz >> wrote: >>> On May 23, 2010, at 11:54 AM, Viktor Klimov wrote: >>> I use PB in unstable network. The server remembers the last answer. Client detection disconnected, connected again, makes entry into the system and calls the function returns the last response (get_last_response). The answer, it returns a deferred saved earlier. If somewhere an error cycle repeats. All of this works until the lost communication does not happen at a time when Twisted sends data to a server. As the server in this situation does not receive a first request, and when you call get_last_response client receives the data that has already received. How can I check if an error in the client arrived data to the server or not? >>> >>> Hi Viktor, >>> >>> I try not to give people a hard time about bad English, but I am having a >>> hard time reading your message. There are a couple of different things I >>> think you might mean and it would be confusing if I tried to explain them >>> all. >>> >>> Perhaps you could attach some Python code that explains exactly what you >>> mean? >>> >>> >>> ___ >>> Twisted-Python mailing list >>> Twisted-Python@twistedmatrix.com >>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python >>> >> >> ___ >> Twisted-Python mailing list >> Twisted-Python@twistedmatrix.com >> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python >> >> > > ___ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] can the reactor be told to stop processing events and to just queue them?
Hello everyone, is there a way to tell the reactor to just queue the events and not to process them for a specific protocol? I have two protocols running on my reactor, one that monitors the network and one for a usb device, I'd like to pause the event processing for the network side when certain msgs arrive on the usb protocol and then unpause it later on. I know I can create a queue and add the network msgs and process them later but I find it redundant to do so when twisted already has an event queue. Thank you, Gabriel ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] can the reactor be told to stop processing events and to just queue them?
On Thu, 2010-05-27 at 14:08 +0200, Gabriel Rossetti wrote: > is there a way to tell the reactor to just queue the events and not to > process them for a specific protocol? No, Twisted doesn't have an event queue (but see below). > I have two protocols running on my > reactor, one that monitors the network and one for a usb device, I'd > like to pause the event processing for the network side when certain > msgs arrive on the usb protocol and then unpause it later on. I know I > can create a queue and add the network msgs and process them later but I > find it redundant to do so when twisted already has an event queue. How about calling transport.pauseProducing() and then later transport.resumeProducing() on the TCP connections? ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] can the reactor be told to stop processing events and to just queue them?
Itamar Turner-Trauring wrote: > On Thu, 2010-05-27 at 14:08 +0200, Gabriel Rossetti wrote: > >> is there a way to tell the reactor to just queue the events and not to >> process them for a specific protocol? >> > > No, Twisted doesn't have an event queue (but see below). > > ok >> I have two protocols running on my >> reactor, one that monitors the network and one for a usb device, I'd >> like to pause the event processing for the network side when certain >> msgs arrive on the usb protocol and then unpause it later on. I know I >> can create a queue and add the network msgs and process them later but I >> find it redundant to do so when twisted already has an event queue. >> > > How about calling transport.pauseProducing() and then later > transport.resumeProducing() on the TCP connections? > > Ok, thanks, I'll try that. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] major changes, release engineering, and learning cost
For clarity: I think Launchpad replacing Trac is a good thing. I realize that's a huge ordeal. However, I don't think the basic ideas are so different that it'd be impossible. As discussed on IRC, the main downside (aka why we can't do it right now) is lack of notifications, so it's hard to integrate stuff like buildbot yet, but that's being worked on. The idea I'm proposing is probably doable without Launchpad, but it's definitely much harder without bzr. Mixing bzr and svn, might work, but the developers definitely need to be using bzr because branching really can't be a pain for it to work. I have diagrammed the quantum-transmogrifier example that I tried to explain in the last email. http://bit.ly/aA20Qs On Thu, May 27, 2010 at 7:02 AM, Glyph Lefkowitz wrote: > > On May 26, 2010, at 5:41 AM, Laurens Van Houtven wrote: > > So, while I can definitely sympathize with a certain animosity towards > trac, and I can appreciate the goals and sensibilities of launchpad, I > will probably flat-out veto any required / process-driven usage of > Launchpad blueprints. Bugs, features, enhancements, etc, are all units > of work that need to be tracked, and it's better to have one kind of > crummy interface for tracking _everything_ than three interfaces, even > three good interfaces, for tracking little bits stuff in different > ways according to arbitrary distinctions. (As someone recently opined > to me, Blueprints are a giant complicated interface for pasting the > URL to a Google Wave into a text field. We might as well skip the text > field and just link straight to the conversation from a Trac ticket.) (was it dash? ;-)) I understand your point of view, but I don't think blueprints are that bad. I'm not saying blueprints aren't fat pointers to URLs, but I just don't think that would necessarily make them less useful. As far as arbitrary distinctions go: I'd think new features are blueprints, and bugs are bugs. It's not very arbitrary in my mind -- which is just a different way of saying "I can't think of any grey areas". (Yes, this means there are very few blueprints. I think that's a good thing :)) I think I understand the reasoning behind your opinion from a project lead/release management/developer perspective: both bugs and blueprints are jobs that still need to be done, similarly tracked for releases, and they both take developer time to be resolved. I don't think this reasoning is wrong. For both users and developers, I think thinking of bugs and new features as separate things makes sense. Furthermore, Launchpad has stuff like milestones and targeted releases, so I don't think the three-good-interfaces thing is really that prohibitive. Personally, I don't feel that split is bad for developers either. (FWIW: yes, I think Launchpad's Whiteboard feature needs extending and it probably needs a comment system. And once you do that, you might indeed wonder what the difference with bugs still is -- but I'm not arguing Launchpad is perfect, I'm arguing it's better than Trac ;-)) Even if blueprints are non-negotiable, I think most of what I said could just as well be applied to Launchpad bugs: you'd treat Launchpad bugs like you treat Trac tickets now. Merge proposals and the reviews they come with are properties of branches in Launchpad, and not of blueprints or bugs (IIRC). So, feel free to scrap blueprints, it's not that big a deal :) > lp:~lvh... isn't a verb. What do you do with that string? :) Sorry, bad emacs VC mode habit. I meant 'create a branch lp:~lvh/...' > > and it turns out FTL travel is really really hard so I need two > > smaller branches lp:~lvh/twisted/quantum-transmogrification-tunnels > > and lp:~lvh/twisted/quantum-transmogrification-ansible. Both are > > good, so they get put back into > > ~lvh/twisted/quantum-transmogrification-ftl-travel. > > > > Each review would verify that all children (if any) have also been > > reviewed. So, the final review is pretty small, as suggested :-) > > The review wouldn't verify that the parent had been reviewed, though. > If you started this process by writing a bunch of code in the q-t-f-t > branch, *that* code would never have been reviewed; unless q-t-f-t > needs to be reviewed in its entirety before landing on trunk. Which is > precisely what I'm trying to avoid. Yeah, this is sort-of fixed in practice by my point (1) below, but requires some conscious effort and discipline from the developer. An alternative idea to just having merges of reviewed branches in q-t, would be to have the review of q-t be "all of the commits that aren't reviewed merges from other branches". That sounds really, really annoying, so I'd rather do it the first way. Specifically, that means "don't do that, branch early and often, merging is easy but branching halfway is confusing". > > > This does not limit a developer's freedom to branch at will, because > > code review is opt-in (merge proposal), not opt-out. If you don't do > > it, that code in that branch isn'
Re: [Twisted-Python] major changes, release engineering, and learning cost
On May 27, 2010, at 4:27 PM, Laurens Van Houtven wrote: > I have diagrammed the quantum-transmogrifier example that I tried to > explain in the last email. OK. With this diagram in mind, I can see that what you're proposing is nearly identical to what I've already proposed, except that you are being very vague as to the *requirements* on when and whether branches get merged. I'm not concerned with the "level of confidence" that you describe (we already have that), but with a modification to the *requirement* that branches be fully reviewed before a merge to trunk, and that the reviewer can block that merge. What I've suggested, simply put, is that we can have branches that land on trunk without being fully code-reviewed, *provided that each commit to that branch was itself code-reviewed*. There are a few fiddly details beyond that, but we seem to be in agreement on that broad picture. So, sorry for a terse response to a message that obviously took a long time to write, but I don't think this merits further discussion :). -glyph ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] major changes, release engineering, and learning cost
When you say merge, do you mean into trunk, or also the submerges into my own feature/review branch? The big problem I can think of is that interfaces are something you should probably have a rough idea about way before any code gets written, but under this system branches get reviewed per feature set, so it takes a very long time before anyone (at least the reviewer, in the worst case also the developer) gets a half-decent view of how the entire thing is going to look when it's finished. I'm not saying interfaces should be set in stone, of course. I just think you should have some basic design that people agree on before you start writing tests, let alone implementation code. (I think this is where blueprints fit in). Laurens ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] Looking for Twisted programmers at Fluidinfo
Apologies for a job posting, but we're looking to hire Twisted people at Fluidinfo (http://fluidinfo.com) . We wrote FluidDB using Twisted from top to bottom. We love Twisted. In fact, we closed a funding deal a week ago and the company's first check is being written to the Twisted Software Foundation. We wrote and use txAMQP, txRDQ, Twisted interfaces to Avro, Zookeeper, and Amazon S3 & EC2. We give talks on Twisted (we have a couple in the upcoming EuroPycon) and I am personally addicted to the myriad slippery beauties of Twisted deferreds :-) So there you go. Want to work (preferably!) in New York in a cool startup with a team of hackers who love Twisted? Of course you do! See http://fluidinfo.com/jobs & google FluidDB or Fluidinfo for more. [We now return you to regular programming.] Terry ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Looking for Twisted programmers at Fluidinfo
Congratulations on the funding! On 28 May 2010 12:56, Terry Jones wrote: > Apologies for a job posting, but we're looking to hire Twisted people at > Fluidinfo (http://fluidinfo.com) . We wrote FluidDB using Twisted from top > to bottom. We love Twisted. In fact, we closed a funding deal a week ago > and the company's first check is being written to the Twisted Software > Foundation. We wrote and use txAMQP, txRDQ, Twisted interfaces to Avro, > Zookeeper, and Amazon S3 & EC2. We give talks on Twisted (we have a couple > in the upcoming EuroPycon) and I am personally addicted to the myriad > slippery beauties of Twisted deferreds :-) > > So there you go. Want to work (preferably!) in New York in a cool startup > with a team of hackers who love Twisted? Of course you do! See > http://fluidinfo.com/jobs & google FluidDB or Fluidinfo for more. > > [We now return you to regular programming.] > > Terry > > ___ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
