Re: SQL*NET over dial-in

From: Joe Halpin <jhalpin_at_netcom.com>
Date: Wed, 10 Aug 1994 20:11:08 GMT
Message-ID: <jhalpinCuC5EL.DzK_at_netcom.com>


In article <32ad4r$1ob_at_isis.imag.fr> despoix_at_isis.imag.fr (Frederic Despoix) writes:
>>>Bart Mendez (bmb_at_bae.bellcore.com) wrote:
>>>
>>> I'm developing an application that will have local and remote users. The
>>> clients will be PCs running a PowerBuilder front-end, and the server will
>>> be an HP 9000 with Oracle7 and SQL*NET. The local users will be connected
>>> to the network via an Ethernet LAN, but the remote users will have to dial
>>> in from remote locations. Unfortunately, there's no choice. What kind of
>>> transport protocol should I use for the remote users? TCP/IP over a SLIP
>>> or PPP connection comes to mind, but I'm not sure if this is the best or
>>> only choice. If it is, what TCP/IP software package(s) for the PC can
>>> handle this?
>>>

 [snip]
>
>Throughput on LS and dial-up are different according to the modulation mode of
>the modem : a LS modem will provide you real 19.2 Kbits per second. A dial-up
>modem will provide you 2400 bps for a 14.4 Kbps established connection, because
>of the modulation !

Not really. There's a difference between the baud rate and the bit rate with most modem protocols. The difference is that the baud rate is the number of signalling elements per second, while the bit rate is the number of bits transmitted.

Most modem protocols encode more than one bit per signalling element, which allows 14.4Kbps to be transmitted over a 2400 baud connection. If you check the figures Procomm or something similar gives you during a file transfer, you can see that there are consderably more than 2400 bps going across the line during a 14.4 connection. With V.42bis enabled, you can get throughput up to 38.4 or better depending on the compressability of the data being transmitted.

-- 
Joe Halpin 
jhalpin_at_netcom.com
---------------------------------------------------------------------------
Received on Wed Aug 10 1994 - 22:11:08 CEST

Original text of this message