TODO

We need to implement response timeouts. For instance, after sending a PDU,
we should expect a response pdu (if the protocol defines it) in a particular
interval, after which, we should timeout and consider that request as failed.
A typical example of where the absense of this can result in a problem is during
unbind. If we initiate an unbind, we normally should wait for an unbind_resp{} 
from the SMSC before we shutdown RX. We should not wait for all eternity... ;)


Track some statistics:
	- Uptime: Tracked by esme_core
	- txcounter: smpp34_tx
	- rxcounter: smpp34_tcprx
	- ttx: timestamp when pdu is sent off by tx
	- trx1: timestamp when pdu is received by tcprx
	- trx2: timestamp when pdu is received by rx
	- trx3: timestamp when pdu is received by esme_core


Build a disconnected socket interface for handling closing and opening of
sockets at the lower level? Or handle disconnections _in_ the smpp34_esme core
itself? Consider patching gen_tcp too

Other ideas worth looking into usability-wise:
	- Behave like gen_tcp and use an {active, true|false} operational mechanism
	- Have smpp34_esme as a simple client, exposing {active, true|false} 
      options,while then gen_esme34 as an ESME framework

We need to rearchitect the ownership of the Sequence number generator. Right
now, only the transmitter smpp34_tx calls out to smpp34_snum to get the 
sequence_number, thus only smpp34_tx can know the sequence_number of an 
outgoing PDU. Right now though, smpp34_tcprx needs access to smpp34_snum when
unbinding since it will send the #unbind{} PDU directly (not via the tx).