We have a handful of customers that will not open up ports in their firewall to allow retrival / sending sql remote messages via FTP.
Question 1: Is there a simple pitch that we can give these customers to open a port? I would guess that ports are open for retrival of such things as virus definitions.
Question 2: Is there a real risk to our customers security wise if we can assume that our FTP server is "safe"
Question 3: In the newer versions of SQL Remote the HTML transport is available. Is it complicated to switch from FTP to HTML? Can the system be mixed where most users still use FTP and the handful that block FTP can use HTML?
Question 4: What is the Performance of HTML vs FTP? Lets say I need to send 1000 messages to 2000 remote databases. Can a server process 2 million plus messages in a reasonable amount of time.
We are using the latest version 12 release of SQL Anywhere / Sql Remote.
asked 11 Jul '12, 16:42
The HTTP support was put in an EBF, and never made it into the documentation -- UNTIL we updated it as part of the SA OnDemand release. Nevertheless, there indeed appear to be some omissions. I have contacted the documentation team about that. Meanwhile, you can find a useful tutorial here: http://dcx.sybase.com/index.html#1201/en/sqlremote/sra-tutorial-http.html
Q1: We're run across many IT departments unwilling to open a port up, hence our creation of the Outbound Enabler (OE) that works with the Relay Server to allow incoming traffic without requiring IT begging and/or heroics. Some customers will open a port, but they require a reverse proxy, often one enhanced with intrusion detection and such. HTTP is likely to be the ONLY inbound traffic supported in the majority of these cases, not FTP.
Q2: Assumptions are scary. FTP would provide file access inside the firewall, and permissions must be managed VERY carefully. It really depends on the IT department involved, but I expect most won't go for it. The Relay Server avoids the problem nicely.
Q3: See Breck's answer.
Q4: In our performance tests, HTTP was comparable to FILE. Larger message "files", which map to HTTP requests, should give better performance, but you should do your own performance testing to find the sweet spot that works best for you under expected loads.
answered 13 Jul '12, 11:55
Q3) It should be very easy to switch the message type from FTP to HTTP/HTTPS. Please replicate all the messages for the remote users you would like to change, before switching the message type. Otherwise you may have to manually copy the messages from the directories in the FTP setting to that in the HTTP/HTTPS setting. It should be no problem to have a mixed setting. But you should test it in your test environment before put it in production.
Q4) To get better performance, you may need to have a dedicated message server on a decent machine, instead of using the consolidated database server as a message server.
answered 13 Jul '12, 11:37