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