| |
DBD::Gofer - A stateless-proxy driver for communicating with a remote DBI - search.cpan.org
by Lost at 1:24 pm EDT, Oct 20, 2008 |
DESCRIPTION ^ DBD::Gofer is a DBI database driver that forwards requests to another DBI driver, usually in a seperate process, often on a separate machine. It tries to be as transparent as possible so it appears that you are using the remote driver directly. DBD::Gofer is very similar to DBD::Proxy. The major difference is that with DBD::Gofer no state is maintained on the remote end. That means every request contains all the information needed to create the required state. (So, for example, every request includes the DSN to connect to.) Each request can be sent to any available server. The server executes the request and returns a single response that includes all the data. This is very similar to the way http works as a stateless protocol for the web. Each request from your web browser can be handled by a different web server process.
Use Cases This may seem like pointless overhead but there are situations where this is a very good thing. Let's consider a specific case. Imagine using DBD::Gofer with an http transport. Your application calls connect(), prepare("select * from table where foo=?"), bind_param(), and execute(). At this point DBD::Gofer builds a request containing all the information about the method calls. It then uses the httpd transport to send that request to an apache web server. This 'dbi execute' web server executes the request (using DBI::Gofer::Execute and related modules) and builds a response that contains all the rows of data, if the statement returned any, along with all the attributes that describe the results, such as $sth->{NAME}. This response is sent back to DBD::Gofer which unpacks it and presents it to the application as if it had executed the statement itself.
|
| |
RE: DBD::Gofer - A stateless-proxy driver for communicating with a remote DBI - search.cpan.org
by dc0de at 8:34 am EDT, Oct 21, 2008 |
Jello wrote: DESCRIPTION ^ DBD::Gofer is a DBI database driver that forwards requests to another DBI driver, usually in a seperate process, often on a separate machine. It tries to be as transparent as possible so it appears that you are using the remote driver directly. DBD::Gofer is very similar to DBD::Proxy. The major difference is that with DBD::Gofer no state is maintained on the remote end. That means every request contains all the information needed to create the required state. (So, for example, every request includes the DSN to connect to.) Each request can be sent to any available server. The server executes the request and returns a single response that includes all the data. This is very similar to the way http works as a stateless protocol for the web. Each request from your web browser can be handled by a different web server process.
Use Cases This may seem like pointless overhead but there are situations where this is a very good thing. Let's consider a specific case. Imagine using DBD::Gofer with an http transport. Your application calls connect(), prepare("select * from table where foo=?"), bind_param(), and execute(). At this point DBD::Gofer builds a request containing all the information about the method calls. It then uses the httpd transport to send that request to an apache web server. This 'dbi execute' web server executes the request (using DBI::Gofer::Execute and related modules) and builds a response that contains all the rows of data, if the statement returned any, along with all the attributes that describe the results, such as $sth->{NAME}. This response is sent back to DBD::Gofer which unpacks it and presents it to the application as if it had executed the statement itself.
AWESOME, now we can perform Database attacks MUCH easier! w00t! |
|
| | |
RE: DBD::Gofer - A stateless-proxy driver for communicating with a remote DBI - search.cpan.org
by Lost at 1:41 am EDT, Oct 22, 2008 |
dc0de wrote: Jello wrote: DESCRIPTION ^ DBD::Gofer is a DBI database driver that forwards requests to another DBI driver, usually in a seperate process, often on a separate machine. It tries to be as transparent as possible so it appears that you are using the remote driver directly. DBD::Gofer is very similar to DBD::Proxy. The major difference is that with DBD::Gofer no state is maintained on the remote end. That means every request contains all the information needed to create the required state. (So, for example, every request includes the DSN to connect to.) Each request can be sent to any available server. The server executes the request and returns a single response that includes all the data. This is very similar to the way http works as a stateless protocol for the web. Each request from your web browser can be handled by a different web server process.
Use Cases This may seem like pointless overhead but there are situations where this is a very good thing. Let's consider a specific case. Imagine using DBD::Gofer with an http transport. Your application calls connect(), prepare("select * from table where foo=?"), bind_param(), and execute(). At this point DBD::Gofer builds a request containing all the information about the method calls. It then uses the httpd transport to send that request to an apache web server. This 'dbi execute' web server executes the request (using DBI::Gofer::Execute and related modules) and builds a response that contains all the rows of data, if the statement returned any, along with all the attributes that describe the results, such as $sth->{NAME}. This response is sent back to DBD::Gofer which unpacks it and presents it to the application as if it had executed the statement itself.
AWESOME, now we can perform Database attacks MUCH easier! w00t!
Thats the trend, yes. Its even the trend for it to be totally open for you to hammer, in the cloud. |
|
|
|
