[vwnc] OpentalkSTST problem
Locked
 
|
I am working on a game and trying to attach a domain model on one computer via STST to a gui on another. The gui forwards displayOn: aGC to the model, but this always times out. I put a breakpoint in the model's displayOn: ("server") and stepped through with the debugger to find it freezes the first time it tries to send a message (displayPixelArray:at:) back to the graphics context ("client").
Any ideas why this is happening? Does STST only support messages sent from the client to the server? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Nope, servers can send messages back as well, as long as they are able to find a connection back to the client. Note that responses are sent back over the same connection that carried the request in. Anyway, I suspect the problem in your case is more basic though.
Despite the fact that Opentalk makes remote requests very transparent, it is still important to set you distributed application up very carefully, making sure that objects that need to reside in the same image do so. That's especially true about objects that end up being parameters of primitive operations, as for example graphics primitives. Primitives can't handle remote objects. So in your case I'd definitely strive to make sure *all* your drawing happens on the client and that the displayOn: calls don't include any remote references. A remote graphics context definitely sounds like trouble. Basically you need to be in very good control of what is happening where in your distributed application. Decide where the image boundaries lie in your communications and keep it that way. Be aware of how message arguments and results are passed (by-reference or by-value) and make sure you don't end up with an uncontrolled explosion of remote references going back and forth. HTH, Martin Ryan Macnak wrote: > I am working on a game and trying to attach a domain model on one > computer via STST to a gui on another. The gui forwards displayOn: aGC > to the model, but this always times out. I put a breakpoint in the > model's displayOn: ("server") and stepped through with the debugger to > find it freezes the first time it tries to send a message > (displayPixelArray:at:) back to the graphics context ("client"). > Any ideas why this is happening? Does STST only support messages sent > from the client to the server? > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] OpentalkSTST problem
|
|
Am 12.06.2008 um 04:12 schrieb Martin Kobetic: > Despite the fact that Opentalk makes remote requests very > transparent, it is still important to set you distributed > application up very carefully, making sure that objects that need to > reside in the same image do so. [...] Martin, IMO your analysis is a very helpful summary. Thanks for sharing your insights. I played around with STST a while ago and the lesson I've learned was: While messages and objects are transparent across multiple images (which is a great achievement), your application architecture is definitely not. It can be tricky to keep the different roles apart, especially if all of them reside in the same image during development. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] OpentalkSTST problem
|
|
In reply to this post by kobetic
> -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf > Of Martin Kobetic > Sent: Wednesday, June 11, 2008 10:12 PM > To: Ryan Macnak > Cc: [hidden email] > Subject: Re: [vwnc] OpentalkSTST problem > > Nope, servers can send messages back as well, as long as they are able to > find a connection back to the client. Note that responses are sent back > over the same connection that carried the request in. Anyway, I suspect > the problem in your case is more basic though. > > Despite the fact that Opentalk makes remote requests very transparent, it > is still important to set you distributed application up very carefully, > making sure that objects that need to reside in the same image do so. > That's especially true about objects that end up being parameters of > primitive operations, as for example graphics primitives. Primitives can't > handle remote objects. So in your case I'd definitely strive to make sure > *all* your drawing happens on the client and that the displayOn: calls > don't include any remote references. A remote graphics context definitely > sounds like trouble. Basically you need to be in very good control of what > is happening where in your distributed application. Decide where the image > boundaries lie in your communications and keep it that way. Be aware of > how message arguments and results are passed (by-reference or by-value) > and make sure you don't end up with an uncontrolled explosion of remote > references going back and forth. Several years ago I was working on an application that uses SmalltalkBroker. We first tried using remote object references but quickly found out that it was too chatty which made it run rather slow. As a result of that experience, when I restructured the Debugger I divided it into two basic components, a client and a server. I made sure that the information that is transferred between the two can be treated as value objects. Initially, the debugger did not operate as a remote debugger, but I decided if Cincom wanted remoted debugging that using client/server design would simplify any modifications needed for a remote debugger. If I ever work on another application that uses opentalk I will strongly resist the temptation to use remote references for simple objects. I would always reserve the use of a remote reference for an application object and make sure that the requests are service requests and the replies are simple value objects. > HTH, > > Martin > > Ryan Macnak wrote: > > I am working on a game and trying to attach a domain model on one > > computer via STST to a gui on another. The gui forwards displayOn: aGC > > to the model, but this always times out. I put a breakpoint in the > > model's displayOn: ("server") and stepped through with the debugger to > > find it freezes the first time it tries to send a message > > (displayPixelArray:at:) back to the graphics context ("client"). > > Any ideas why this is happening? Does STST only support messages sent > > from the client to the server? > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] OpentalkSTST problem
|
|
> If I ever work on another application that uses opentalk I will strongly > resist the temptation to use remote references for simple objects. I would > always reserve the use of a remote reference for an application object and > make sure that the requests are service requests and the replies are > simple value objects. > > I found the same thing when I was working on Opentalk code.. except I was making a game. What I needed to do was to constantly update random bits of objects that clients had fetched from the server because constantly talking to the server over references was way too chatty. In the end I made a replicating object space - you could ask for something from the server and it'd give it to you as a value, then mark the objcet on the server as immutable and any further changes to that object would be pushed to any client that was interested in it. There was an initial startup cost that quickly disappeared as the client fetched everything it wanted/needed. As it GC'd objects, it'd tell the server that it no longer cares about updates for that object. It worked very well. In this scenario, my objects weren't technically 'value' or 'reference'... I was sharing an auto-replicating object space. Cheers, Michael _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Terry Raymond
I have used VisualAge Server Smalltalk to develop a middleware system.
I contemplated using remote objects, but chose to use pass by value for simplicity. You may find this interesting - from one of the developers of VA Server Smalltalk Rick DeNatale... http://talklikeaduck.denhaven2.com/articles/2006/07/29/about-me "...The goal of Smalltalk Distributed was transparent distribution of Smalltalk. Our approach was to implement a distributed implementation of the Smalltalk object model including object storage and garbage collection, message sending, and distributed threads of execution complete with non-local returns. This was all done completely in Smalltalk, using lots of tricks in using metaprogramming much like what the wizard Ruby metaprogrammers do. This project was technically interesting, and got some use by customers, but it was most valuable as a learning experience. In retrospect, the transparency was both a neat idea, and a problem. Putting a black box around a distrubuted system is probably not as good an idea of putting a distributed system together out of black boxes..." _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |