[V4RB] Writing a simple server

[Frank Bitterlich]

Hi Jon,

I've done something similar; although the backend here is not a
Valentina DB but rather a pre-existing MS SQL-Server DB. (I _wish_ it
was Valentina, though. :)

The one thing I stummbled over was that I initially picked the standard
HTTP port 80, and has lots of myterious crashes. After I added decent
logging, I found out that the reason was a huge amount of attempted
buffer overflow attacks from the outside. After I changed that port (and
closed the port 80 on the firewall just for good measure), everything
went fine.

There are some reports of the RB4 socket failing when multiple
connection requests arrive at the same time, and because of this I'm
destroying and re-creating my socket every other hour, and so far it
runs pretty flawless.

I think the decision if you want to use multithreading depends on how
much work your application does between the retrieval from the database
and the HTTP response. If that's not too much work, I'd rather go for a
single-socket, single-threaded application. But it also depends on the
type of client (a web browser? Or a client application?) and the number
of clients/expected hits.

And don't forget to use proper Authentication. Especially if you're
going to use port 80. :) Oh, BTW, you won't be able to use (listen on)
one of the well-known (low-numbered) ports on OS X unless your app is
running as root, which I don't recommend for this.

Cheers,
   Frank+++

jda wrote:
> 
> Hi all.
> 
> I'm thinking of creating a simple server using RB and V4RB to serve
> bibliographic data over the web. I've been playing with sockets and
> HTTP, and I think it will be rather easy to implement. Basically,
> I'll set up a "listener" and, when it receives a query, fetch the
> data, organize it, and send it back to the browser. FWIW, I'll
> probably wait for RB 5 to actually release this because the new
> ServerSocket class is a lot more robust than the Socket control
> offered in earlier versions.
> 
> I'm wondering if anyone else on this list has done something like
> this, and if so what their experience was. What are the problems that
> I should be anticipating (like multithreading -- I'm happy to have
> queries queued, because I don't intend this to be an
> industrial-strength solution, but even so might there be problems
> with concurrent hits)? Is there a limit on the amount of data one can
> return?
> 
> Thanks,
> 
> Jon



--
Günter Schmidt & Co. oHG         
Frank Bitterlich             eMail: bitterlich at gsco.de
Schlosserstr. 4              WWW:   http://www.gsco.de/gsco
D-60322 Frankfurt            Tel.:  069 / 156809-29
GERMANY                      Fax:   069 / 156809-28