Connections and Sessions in TCP/IP

 Connections and Sessions in TCP/IP

TCP/IP is a connection-based protocol:

- To start any communication a connection must be arranged.

- Open a connection to start communications.

- Close a connection to end communications. 

- Meaning all communications between parties are arranged over a connection.

- A connection is established before any data transmission begins.

- Over TCP/IP, we'll always need to establish a connection between clients and servers in order to enable communications. 

Moreover:

Deliveries over the connection are error-checked,

If packets arrive damaged or lost, then they are resent (known as retransmission).

It's really important that we continually monitor what connections are opened and closed.

between a recipient and sender because the more connection that we have open

The more performance-based issues we may run into. 

We will always need to establish a connection from a client application to a Postgres server Or MySQL server over TCP/IP in order to interact with it.

We have this concept of a session,

What a session is that marks the start and end of the connection.

A session is essentially a period between the start and end of a connection that may we have between a client and a Postgres server. 

Within a session, we encapsulate interactions between a client and a server in units that we call transactions. 

So when we start connecting: 

- Connecting starts a session.

- Ending the connecting ends the session.  

In a database session, many transactions can occur during a given session.

Each transaction does work to commit changes to the database (updating, inserting, or deleting records).

Aside: the UDP Protocol:

The internet also offers the UDP protocol. 

UDP stands for User Datagram Protocol.

 

UDP is much simpler than TCP: 

hosts on the network send data (in units called datagrams) without any connections needing to be established.

TCP vs UDP:

If TCP is like building highways between houses before sending packages between them, then UDP is much like sending over a carrier pigeon from one house to another in order to deliver packages 

You don't know whether the pigeon will head in the right way, drop your package along the way, or encounter an issue mid-travel. 

On the other hand, there is less overhead to use UDP than managing a connection over TCP / building a highway.

When speed is more important than reliability, especially when applications need to stream very small amounts of information quickly (smaller packages of information mean fewer issues with reliability), then UDP is preferred. 

A lot of real-time streaming applications, (e.g. live TV streaming, Voice over IP (VoIP)) prefer UDP over TCP. 

Since UDP does not need to retransmit lost datagrams, nor does it do any connection setup, there are fewer delays over UDP than TCP. 

TCP's continuous connection is more reliable but has more latency.

Transactions

A transaction is a single logical unit of work that accesses and possibly modifies the contents of a database. 

Transactions access data using read and write operations. 

In order to maintain consistency in a database, before and after the transaction, certain properties are followed. 

These are called ACID properties.

Transactions capture logical bundles of work

Work is bundled into transactions so that in case of system failures, data in your database is still kept in a valid state (by rolling back the entire transaction if any part of it fails). 

To ensure a database is consistent before and after work is done to it, databases use atomic transactions, and actions like commits and rollbacks to handle failures appropriately.

Why bundle work into transactions?

- Database systems can fail.

- We want the database to always be in a valid state. 

- look into ACID properties

The relational database is transactional:

All changes to data are made through units called transactions.

- Either a single change or multiple changes.

- Executed in an ordered sequence.

An operation that either succeeds altogether or fails altogether as a unit.

ACID properties of transactions

In the context of transaction processing, the acronym ACID refers to the four key properties of a transaction: atomicity, consistency, isolation, and durability.

Atomicity

All changes to data are performed as if they are a single operation. That is, all the changes are performed, or none of them are.

For example, in an application that transfers funds from one account to another, the atomicity property ensures that, if a debit is made successfully from one account, the corresponding credit is made to the other account.

Consistency

Data is in a consistent state when a transaction starts and when it ends.

For example, in an application that transfers funds from one account to another, the consistency property ensures that the total value of funds in both the accounts is the same at the start and end of each transaction.

Isolation

The intermediate state of a transaction is invisible to other transactions. 

As a result, transactions that run concurrently appear to be serialized.

For example, in an application that transfers funds from one account to another, the isolation property ensures that another transaction sees the transferred funds in one account or the other, but not in both, nor in neither.

Durability

After a transaction successfully completes, changes to data persist and are not undone, even in the event of a system failure.

For example, in an application that transfers funds from one account to another, the durability property ensures that the changes made to each account will not be reversed.