[NTLUG:Discuss] OT sql communication between nix boxen

[Leroy Tennison]

Fred James wrote:
> All
> The central database and server ...
> SGI IRIX 6.4 (soon to become 6.5.30)
> Oracle 8.0.4 (soon to become 8.1.7 - sorry that's our limit at the moment)
> 
> Other SQL databases on other computers want to communicate (GUI 
> interactive not required - this is behind the scenes stuff)
> 
> One box in particular is said to be a fairly recent version of Red Hat 
> Enterprise - have not confirmed that
> 
> Could someone outline the communication layer, please?  Or point me 
> toward some "for dummies" documentation?
> 
> Thank you in advance for any help you may be able to offer
> Regards
> Fred James
> 
> 
> _______________________________________________
> http://www.ntlug.org/mailman/listinfo/discuss
> 

Well, I'm not sure I clearly understand at what level you are wanting to 
understand the communication layer, but hopefully even if I'm off base 
it will help to clarify things and move the discussion in the right 
direction.

I know very little about Oracle but, in general, communication is at 
several layers.  I'm going to skip the physical and data link layer 
because I'm assuming the computers are attached to an interconnected 
network with functioning network software.  Since I didn't see Microsoft 
or Novell in the equation I'm going to assume we are talking about 
TCP/IP (as opposed to either NetBEUI or IPX) as the 'carrier' protocol 
for communication.

The initiator of the communication has to know how to contact the 
responder by some identifier (name such as DNS name or IP address) and 
port which the responder software is listening on.  This is one aspect 
of configuration.  The 'port' part may be hidden by the vendor's 
software if the vendor has hard-coded a set value on both ends.  (I'm 
using the term initiator and responder to avoid the confusion of a 
server acting as a client.)

Depending on the capabilities and configuration, the IP traffic (or data 
portion of same) may or may not be 'secure' (encrypted).  If it's 
optional this may be another configuration setting (or group of same) 
which must agree on both ends.

Whether the actual protocol traffic is encrypted or not, there is 
probably some kind of authentication and exchange of capabilities which 
takes place at the start of communication.  The authentication is almost 
assuredly a configuration issue on both ends, the responder has to know 
something about the initiator and the initiator has to provide that 
information to the responder.  The capabilities part may or may not be 
configurable (depends on whether there are options).

Finally (I think) there's what I'm going to call a product-specific 
communication protocol.  Again, I'm using this term to avoid having to 
try and distinguish between transport, session, presentation and 
application layer components of this communication.  First of all, I 
don't know the specifics.  Second, no one may know all of them except 
the software vendor.  Third, as long as it works we really don't care. 
The point here is that there may be additional configuration to do if 
the product has options.

That's a generic overview as long as there's no firewall or other kind 
of blocking device between the initiator and responder.  If there is 
then there's configuration for those device(s) to allow the 
communication to pass between the endpoints unhindered.