| Author |
Message |
|
| vim |
Posted: Thu Dec 11, 2008 6:45 am |
|
|
|
User
Joined: 01 Oct 2008
Posts: 19
|
hi, i am implementing an application in erlang, and i a methodological question pooped up.
in general i have a database which is accessed by the client. the client input is processed into database basic actions that change the database. in parallel the client can get events updates with no direct connection to his operations.
the question is, how should i implement the process between the client and the database. i can pass the client request which is being parsed and transformed in two forms:
1. pipe - first process gets the input and pass the output to the next module, etc. till it get to the database as a simple operation.
2. services - each process is a function and can all it with a gen_server, one-by-one giving the last service output as an input to the next service. i think its more OTP like.
...so, which of you who survived till here what are your thoughts? any flavor i should prefer? or is it just semantics? is one is better 'good practice'?
thanks for your help. |
|
|
| Back to top |
|
| Mazen |
Posted: Thu Dec 11, 2008 10:55 pm |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
Hmm I'm probably asking this because it is late and I just had a little bit of too much wine at the restaurant but WHAT exactly are you trying to do? Can you elaborate please?
/M |
|
|
| Back to top |
|
| vim |
Posted: Sat Dec 13, 2008 8:14 am |
|
|
|
User
Joined: 01 Oct 2008
Posts: 19
|
what i am trying to do is a web application, actually a web game. so the gui is at the client browser, and the rest of the application is at the remote server.
the application is for multiple users. this means the user can get response because of other clients actions. the application core is the response system, which is not streaming in time, but breaks the time line into 'ticks'. all the inputs from users are synced and calculated each 'tick' and the proper response is sent to each client.
my question was regarding the 'pipes' which pass and process the user input into the core. each such pipe is made out of modules, which process and do actions on the user input.
the question is: should i implement those modules as 'pass through' modules, or is it better to make them as services which return their result, so i can use a central gen_server to invoke them one-by-one, and finally pass the result to the core?
hopes it clears up things, and thanks for your help.
any comments are welcome! |
|
|
| Back to top |
|
| Mazen |
Posted: Sat Dec 13, 2008 9:35 am |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
Hi Again,
Ok I think I got what you are asking. Basically if you should use specific processes to represent your clients or just "static" calls.
It all depends on the intended behaviour of the clients but I would say that it would be a good idea to have them as seperate processes because of 1 reason (I don't know if it is applicable in your case).
Isolated state; If you don't have a process per player then you will have to organize the communication between them in some way... perhaps a shared table (ouch) or by using the "core" processes to serialize everything. Probably there are a lot of actions that clients can do to eachother without necessarily notifying the core system and these are easier to handle between two processes and therfore ofloads the "core". If a client dies the state goes with it (trap exits + put them under simple_one_for_one supervisor to restart then nicely).
BTW is the communication done through http requests or is it on tcp/ip level (from e.g. an applet)?
A term that comes into mind is "Seperation of concerns". Don't try to have 1 big process do everything... divide it up and communicate inbetween instead.
/M |
|
|
| Back to top |
|
| vim |
Posted: Fri Dec 26, 2008 11:58 pm |
|
|
|
User
Joined: 01 Oct 2008
Posts: 19
|
i don't think i can have a process per player, because the client will use the browser as an application, (over tcp/ip of course). i did thought of using a shared table, but the amount of interaction is well defined.
another question popped in my head when i read your answer, does the threads that use of gen_server, use the same resource? if the answer is yes, do i need another node to have another gen_server resource, or am i way off? |
|
|
| Back to top |
|
| Mazen |
Posted: Sun Dec 28, 2008 1:09 pm |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
gen_server is just a behaviour... each process you create (there are no threads) can be a gen_server behaving process. Then if you have a process A which is a gen_server and you have X number of processes communicating with process A then that communication will all be syncronized (to avoid raceconditions since A has a state usually)
vim wrote: i don't think i can have a process per player, because the client will use the browser as an application, (over tcp/ip of course). i did thought of using a shared table, but the amount of interaction is well defined.
another question popped in my head when i read your answer, does the threads that use of gen_server, use the same resource? if the answer is yes, do i need another node to have another gen_server resource, or am i way off? |
|
|
| Back to top |
|
| vim |
Posted: Tue Dec 30, 2008 7:39 am |
|
|
|
User
Joined: 01 Oct 2008
Posts: 19
|
Quote: gen_server is just a behaviour... each process you create (there are no threads) can be a gen_server behaving process
that's exactly what's unclear to me, when i write a new module which is defined as a gen_server behaviour, i actually call gen_server functions, e.g. gen_server:call(something), i count on the gen_server code to call my handle_call function in return, hiding from me the server always loop.
my question is: does this resource is shared? say i have many modules which defined as gen_server behaviour, they all call gen_server:call, do thay all use the same resource? or all those calls are truly parallel. |
|
|
| Back to top |
|
| Mazen |
Posted: Tue Dec 30, 2008 11:28 am |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
vim wrote: ... or all those calls are truly parallel.
Yes they are truly parallel.
You can verify this by having each callback (e.g. handle_call) to print out the process ID of each call. They are all different for each gen_server you spawned. |
|
|
| Back to top |
|
|
|