borg Geschrieben October 30, 2012 at 14:35 Geschrieben October 30, 2012 at 14:35 The description for the new protocol is online: nline: http://www.tinkerforge.com/doc/Protocol_20.html We would love to get some productive criticism . Zitieren
neilcsmith_net Geschrieben November 2, 2012 at 16:00 Geschrieben November 2, 2012 at 16:00 Well, I thought I'd make the first English response - have tried to follow some of the discussion in the German forum with Chrome's auto-translate. Not very easy! The new protocol seems a good step, though hopefully updating software to work with them won't be too difficult. Having last week written the bulk of the infrastructure for binding with Praxis, I particularly like the planned improvements to enumeration. One thing I find somewhat frustrating is the current blocking / timeout mechanism for some methods (particularly as Praxis is designed around a non-blocking architecture so I have to work around it!). Given the desire to make things work more robustly in case of failure, and with the addition of the sequence number to the protocol, might it be possible to rethink the bindings to return Futures rather than actual values? I'm working with Java where this would be fairly easy to implement using a map of ID to Future. I'm not sure how easy it would be across all the languages you're supporting though. Best wishes, Neil Zitieren
borg Geschrieben November 4, 2012 at 23:40 Autor Geschrieben November 4, 2012 at 23:40 The new protocol seems a good step, though hopefully updating software to work with them won't be too difficult. Everything but the enumeration process should stay the same for someone that uses our bindings. Having last week written the bulk of the infrastructure for binding with Praxis, I particularly like the planned improvements to enumeration. One thing I find somewhat frustrating is the current blocking / timeout mechanism for some methods (particularly as Praxis is designed around a non-blocking architecture so I have to work around it!). Given the desire to make things work more robustly in case of failure, and with the addition of the sequence number to the protocol, might it be possible to rethink the bindings to return Futures rather than actual values? I'm working with Java where this would be fairly easy to implement using a map of ID to Future. I'm not sure how easy it would be across all the languages you're supporting though. Best wishes, Neil It would (with the current and with the new protocol) be possible to implement Bindings that return a Future Object instead of the current blocking behavior. This would probably be quite hard to generate for some of the languages and it would likely be hard to understand for people that are just starting programming. If you want to try to implement something like that, your Bindings will need a queue for the Future Objects per function id. Answers to requests are guaranteed to come in the correct sequence. So you can add the data of the latest request to the current head of the queue and pop it. A newly generated Future Object will be put at the end of the queue, respectively. Does that make sense ? Zitieren
neilcsmith_net Geschrieben November 6, 2012 at 13:09 Geschrieben November 6, 2012 at 13:09 Everything but the enumeration process should stay the same for someone that uses our bindings. Good to know, and shouldn't make updating too hard. I guess there's no easy way of making the bindings work with either protocol is there? It would (with the current and with the new protocol) be possible to implement Bindings that return a Future Object instead of the current blocking behavior. This would probably be quite hard to generate for some of the languages and it would likely be hard to understand for people that are just starting programming. Yes, I came close to forking the current bindings to do that, but have ended up going with an approach that I don't have to (essentially an intermediary proxy that is updated by callbacks). However, I still believe that Futures or something similar would be useful in the bindings; or, at least given the new protocol's intention to handle parts of the system being unavailable, a way of making things fail fast. Maybe I'm wrong, but in the current bindings doesn't any message that is not replied to cause the call to timeout - essentially bringing everything juddering to a halt for 2.5 seconds? If you want to try to implement something like that, your Bindings will need a queue for the Future Objects per function id. Answers to requests are guaranteed to come in the correct sequence. So you can add the data of the latest request to the current head of the queue and pop it. A newly generated Future Object will be put at the end of the queue, respectively. Does that make sense ? Yes, though my thought was more along the lines of a single map of sequence number to Future held in the IP connection. The new spec does talk about you not guaranteeing correct sequence order in future! Zitieren
AuronX Geschrieben November 6, 2012 at 16:03 Geschrieben November 6, 2012 at 16:03 Yes, any unreplied message with an expected response takes the system 2.5 Seconds ^^ The sequence numbers are just 4 Bits, so a map of Sequence number to Future would collide way too often for a reliable system. Zitieren
borg Geschrieben November 6, 2012 at 18:12 Autor Geschrieben November 6, 2012 at 18:12 I can't imagine a system where we ever return an answer for the same FID in a wrong sequence. I think we can safely add that to the spec. A Brick that returns responses to requests to two different Bricklets in a "wrong order" could however easily happen if we ever have a multicore Brick or add real threading to the Brick firmwares. However, the Bindings could implement the sequence number per FID and then the 4 bit would likely suffice again, even if we didn't guarantee the correct order for requests with the same FID. Implementing something like "Future Objects" as a general concept in all of our Bindings would be cool, but i really don't know if it is worth the effort. Especially if we consider that the first steps will get harder for someone that just starts to learn programing. Zitieren
neilcsmith_net Geschrieben November 6, 2012 at 19:42 Geschrieben November 6, 2012 at 19:42 The sequence numbers are just 4 Bits, so a map of Sequence number to Future would collide way too often for a reliable system. Oops! Misread the size and how quickly that wraps. That wasn't my intended meaning of "fail fast"! How about a hash of UID, function ID and (if needed) sequence ID? The idea being that this is all managed in IP connection. Implementing something like "Future Objects" as a general concept in all of our Bindings would be cool, but i really don't know if it is worth the effort. Especially if we consider that the first steps will get harder for someone that just starts to learn programing. You could theoretically put the existing API on top of the Future one - creating methods that block and timeout on the Future.get(). I realise the need to keep this simple for someone just starting to learn programming - at the same time, that timeout could be a big gotcha for the beginner too! Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.