1 |
On Tue, Jan 24, 2012 at 06:14:22PM +0000, Mick wrote: |
2 |
> On Tuesday 24 Jan 2012 17:08:43 felix@×××××××.com wrote: |
3 |
> > I know, in general, what proxies do -- caching, filtering, and |
4 |
> > bypassing firewalls. I have even written a couple of very special |
5 |
> > purpose proxies. Now I need one for work, and don't realy want to |
6 |
> > write another custom special purpose when it seems there must be a |
7 |
> > canned one which can do the job. |
8 |
> > |
9 |
> > We have some vendors who transact business over special ports with |
10 |
> > custom protocols. We pay for these connections, and we only have two |
11 |
> > of them, good enough for QA, but when a developer needs to test code, |
12 |
> > they have to drag their machine over to QA and schedule time with one |
13 |
> > of these connections. What we need is a proxy which can take any |
14 |
> > number of connections on our side and funnel everything into one or |
15 |
> > two vendor connections. I don't know enough of the proxy jargon to |
16 |
> > know how to describe it. I imagine some kind of NAT. No filtering or |
17 |
> > caching; firewall penetration will be taken care of elsewhere. |
18 |
> > |
19 |
> > Any suggestions, or proxy education hints? |
20 |
> |
21 |
> I'm not entirely clear of your use case scenarios and the constraints you are |
22 |
> trying to address with a proxy (e.g. why the developer does not connect |
23 |
> directly to the vendors port(s) to access their service? ) but I'll guess that |
24 |
|
25 |
Because if the devs connect directly to the vendor, they will take |
26 |
over the limited connections we are allowed. Thus they need |
27 |
throttling and/or some kind of NAT. |
28 |
|
29 |
> you probably need a reverse proxy/load balancer arrangement - something like |
30 |
> pound, portfusion, or even nginx? BTW, did I mention apache mod_proxy? I am |
31 |
> not sure what authentication arrangements you need to access your vendors |
32 |
> ports, if you have VPNs or other secure tunnels between your site and the |
33 |
> vendors', but let's say I'd read up on reverse proxies as a start. |
34 |
> |
35 |
> This should make the transaction transparent for your devs, they won't |
36 |
> necessarily know which vendor they end up with after they hit your URL, but I |
37 |
> am not sure if it will satisfactorily address the issue of scheduling time for |
38 |
> a connection with your vendors at times of high demand. Once ports or vendor |
39 |
> service limitations are reached the connections will eventually become |
40 |
> saturated. |
41 |
|
42 |
I don't think saturation is a problem with the kind of dev work we do; |
43 |
our production systems handle hundreds of thousands of transactions an |
44 |
hour over a single connection. The real problem is that if devs grab |
45 |
that connection, production would stall immediately, so we have a |
46 |
separate connection for QA which devs will have to share without |
47 |
hogging; thus some proxy to funnel all requests into the single |
48 |
channel. Altho there is some possibility of the QA channel turning |
49 |
into two, that still needs to be shared amongst a dozen devs and QA. |
50 |
|
51 |
I'll look into all those buzzwords :-) |
52 |
|
53 |
-- |
54 |
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. |
55 |
Felix Finch: scarecrow repairman & rocket surgeon / felix@×××××××.com |
56 |
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 |
57 |
I've found a solution to Fermat's Last Theorem but I see I've run out of room o |