I have always been fascinated with data communication. In the early days of the internet I devoted most of my time on the TCPIP standard, living and breathing the protocol. There were other standards around at the time, IPX/SPX, SNA and DECnet but it wasn’t long before TCP/IP became the defacto standard for communication. In those early days when security was quite open and folk with the technical skills were considerate and trustworthy, we used to hop around the world from system to system with ease. I loved the thought that with a few keystrokes I could be on systems in Germany, then in China and on to Brazil.
For systems to be able to speak to each other they had to be able to speak the same language, TCP/IP. At a basic level, there are two sides to this protocol, connection-orientated (TCP) and connectionless (UDP). UDP is pretty much a free for all where everyone talks at once. This is good for shouting but you can’t have a decent conversation, you just hope everyone hears you. TCP, the connection orientated side is the opposite and is how most trusted systems talk. It rules the roost if you want to have a decent conversation. TCP is how your browser connects to Google and how your traffic zips around the internet. TCP has a lot of cool features like guaranteed delivery and error checking.
TCP is pretty much a one to one conversation, but the initiator needs to setup the initial connection. There is always one side that wants to start the conversation, that side knows who it needs to talk to via its IP Address. To establish and setup a conversation the initiator needs to setup what we call a three-way handshake. It goes something like this. Side A sends a connection request (SYN) to side B. Side B acknowledges (SYN-ACK) that connection attempt to A and then A sends an acknowledgment back.
TCP is also the way God talks to us personally, a three-way handshake that has guaranteed delivery and error checking. He is always the initiator of the conversation [John 6:44]. He knows where to find us [IP Address], we are pretty much blind to the fact that he is there until we get the first SYN. He sends the SYN and waits for the SYN-ACK. If we respond, then he replies back with the final piece of the connection, the ACK. Then the real conversation can begin. All three stages of the connection setup are distinct so they can’t be confused with each other. All three stages must be performed in that order. If one of the stages does not happen communication cannot occur. It is how the standard works.
In our lives we have experienced this as well. When you want to communicate with someone, you must start the process. You need the person to acknowledge you and when they do you reply back with an acknowledgement. Just like our natural earthy conversations and our data communications, God is initiating that conversation with us. He sends the SYN to us individually and personally. It is just a matter of us sending the SYN-ACK back to Him.
But here’s the thing, to ensure conversation setup in TCP doesn’t get stale there is a feature called SYN timeout. This is usually set to 2 seconds for first attempt 4 and then 8 seconds, three strikes your out type of thing. If the end system doesn’t ACK the SYN after these three attempts, then the initiator figures the other system is just not listening.
I don’t believe that God will ever stop sending the SYN’s, but I think there is a danger that we become accustomed to not responding [Ps 95:7-8]. If you have never responded to Gods session establishment process can I encourage you to do so and open up this connection. The connection opens up a conversation that has guaranteed delivery and lots of error checking. Let the conversation begin with that three-way handshake.