Golang tcp socket read gives EOF eventually

I have problem reading from socket. There is asterisk instance running with plenty of calls (10-60 in a minute) and I'm trying to read and process CDR events related to those calls (connected to AMI).

Here is library which I'm using (not mine, but was pushed to fork because of bugs) https://github.com/warik/gami

Its pretty straightforward, main action goes in gami.go - readDispatcher.

buf := make([]byte, _READ_BUF)    // read buffer
    for {
        rc, err := (*a.conn).Read(buf)

So, there is TCPConn (a.conn) and buffer with size 1024 to which I'm reading messages from socket. So far so good, but eventually, from time to time (this time may vary from 10 minutes to 5 hours independently of data amount which comes through socket) Read operation fails with io.EOF error. I was trying to reconnect and relogin immediately, but its also impossible - connection times out, so i was pushed to wait for about 40-60sec, and this time is very crucial to me, I'm losing a lot of data because of delay. I was googling, reading sources and trying a lot of stuff - nothing. The most strange thing, that simple socket opened in python or php does not fail.

• Is it possible that problem because of lack of file descriptors to represent socket on mine machine or on asterisk server?
• Is it possible that problem in asterisk configuration (because i have another asterisk on which this problem doesn't reproduce, but also, i have time less calls on last one)?
• Is it possible that problem in my way to deal with socket connection or with Go in general?

go version go1.2.1 linux/amd64

asterisk 1.8

Ok, problem was in OS socket buffer overflow. As appeared there were to much data to handle.

So, were are three possible ways to fix this:

• increase socket buffer volume
• increase somehow speed of process which reeds data from socket
• lower data volume or frequency

The thing that gami is by default reading all data from asterisk. And i was reading all of them and filter them after actual read operation. According that AMI listening application were running on pretty poor PC it appeared that it simply cannot read all the data before buffer capacity will be exposed.But its possible to receive only particular events, by sending "Events" action to AMI and specifying desired "EventMask". So, my decision was to do that. And create different connections for different events type.