Don't be sad, Wfranc. I actually didn't realize anyone had abrogated Ayn's hero for their business name, but I'm sure she would be happy. Anyway, I know you can resist the teeth .
*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/
"It's hard to believe in something you don't understand." -- the sidhi X-files episode
Originally posted by galathaea
Don't be sad, Wfranc. I actually didn't realize anyone had abrogated Ayn's hero for their business name, but I'm sure she would be happy. Anyway, I know you can resist the teeth .
I like it, because I honestly have never seen Galathaea smiling like that before.
Okay, I pay you back
Well.. I guess I know the answer now. 10 smily limit (enforced by radar). And while I was cutting jobs from my chorus line, souldog has now fell ill to the saddy bug....
Ok how about this one: a bipartite graph and Tarski walk into a bar...
*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/
"It's hard to believe in something you don't understand." -- the sidhi X-files episode
Hey Galathaea, if I may I would like to ask you a programming question. Do you know of a pattern for the following problem.
I will issue an unknown number of requests for data across a socket. These will go through an application gateway and be distributed to some number of running apps. I want to capture when all the apps have responded and then act on the data.
Socket is of course asynchronous.
My solution is to create a "Job" which will have a unique ID and a count of the number of reponses it is expecting. It will also have a dynamically sized array to hold the data sent back. Each time a data item is received the count is decremented and when it reaches zero the array is sent off.
Just wondering if there is an established and superior way to handle this?
Wakeup in the morning and kick the day in the teeth!! Or something like that.
"i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."
Originally posted by souldog
ahhhhh!! thanks. I am all better now
I thought you were really ill, but now when saw you smiling again, I felt great again too,
Here for you, dogsoul can now be souldog
Sorry I have to delete all of your smilies in the quote as..... I have to use it in my own post
Well, all the smilies stick their ears together... how beautiful they are..
Originally posted by souldog
Hey Galathaea, if I may I would like to ask you a programming question. Do you know of a pattern for the following problem.
I will issue an unknown number of requests for data across a socket. These will go through an application gateway and be distributed to some number of running apps. I want to capture when all the apps have responded and then act on the data.
Socket is of course asynchronous.
My solution is to create a "Job" which will have a unique ID and a count of the number of reponses it is expecting. It will also have a dynamically sized array to hold the data sent back. Each time a data item is received the count is decremented and when it reaches zero the array is sent off.
Just wondering if there is an established and superior way to handle this?
I think we can all agree this is topical...
Well, it looks to me like everything has been pared down to the essentials. I am not sure how you are communicating between apps (probably something like COM or if they're your own apps, any IPC like messages or what have you) or even if that is relevant here. That has its own set of designs which vary widely on the circumstances.
The basic idea is just that you are building a proxy to data requests. So if this system is to be included in a larger system at some point, you will want to make your proxy as non-intrusive as possible. I mean by this that the objects talking to the proxy should not need to know anything about how the proxy is setting up a socket and communicating to the application gateway. They should see the proxy as the request object.
Also, I am a little uncertain what is known and what is unknown about the number of requests. There could be ways to handle responses using linking techniques rather than reference counting, but think of the request like a smart pointer. Which ever method of keeping track of the separate requests best suits your objective is fine here.
I don't quite understand the purpose of the unique ID, but it does add that human touch...
So basically, I see you asking about
\
-G==socket==P
/
where the branching indicates communications with the applications, G is the gateway, P is the proxy. Some other suggestions that pop to mind are just to note that if I were building this I usually keep my objects broken up quite finely. So my "gateway" would consist of a server-side socket state-engine system and a message relay system, with all the associated helper classes (like messages). The proxy would consist of a client-side socket state-engine system and proxy interface, again with helpers. But that's the kind of details that crop up in implementation anyways.
Anyways, that's one way of answering your question. Another way would be that if you are asking for established professional frameworks for this, then you have things like ACE (and Active Objects are actually much much much elaborated buggers for just these kind of distributed computing needs), CORBA, and the ever-avoided-by-me-though-I-don't-know-why DCOM.
*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/
"It's hard to believe in something you don't understand." -- the sidhi X-files episode
Yah, I am writing everything to the left of P and part of P.
??? is a server on a private network spanning a bunch of universities, P acts as a control mechanism which processes requests from ???? and translates them into my protocol. I am aware of ACE and have it, but don't have time to learn how to use it right now. I have implemented the gateway as you are describing. Thanks.. I am working on this whole thing kind of alone and sometimes just need to ask somebody "Hey, am I crazy"
Wakeup in the morning and kick the day in the teeth!! Or something like that.
"i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."
Bookmarks