Why does SendApiCmd return header and body concatenated

[tomponline]

Hi,

When using SendApiCmd function, the response is the API headers plus the actual response body combined.

This occurs here:

https://github.com/cgrates/fsock/blob/master/fsock.go#L329

Would it be possible to delimit the hdr from the body (either by changing the type of the channel to send a struct containing header and body properties) or by putting a delimiter character of some sort.

It would be most useful to have the SendApiCmd only return the body of the response, which could be modified to detect errors in the header, but still only return the body.

[tomponline]

The other type of 'events' on the channel, such as command responses and events do not sender the headers:

https://github.com/cgrates/fsock/blob/master/fsock.go#L314

[tomponline]

This PR seems to do the trick #5

[danbogos]

Hey Tom,

Would need a bit of time to check the impact since we use processing of
the events in our session manager.

Thanks,
DanB

On 10.06.2014 23:10, TomP wrote:

This PR seems to do the trick #5 #5

—
Reply to this email directly or view it on GitHub
#4 (comment).

[tomponline]

Thanks. How do you use the API response string currently? Do you extract the content-length line party and then use that as a length to read the response body? How do you know where the header starts (as the response text has the empty newline that delimits the header from the body removed)

[danbogos]

We only process events from ReadEvents and check for error in case of
SendApiCmd (use that for commands like call originate). The only issue is
ReadEvents for us and that is why I need to check it. However not enough
hours on the day :-).

DanB.
Am 14.06.2014 11:47 schrieb "TomP" notifications@github.com:

Thanks. How do you use the API response string currently? Do you extract
the content-length line party and then use that as a length to read the
response body? How do you know where the header starts (as the response
text has the empty newline that delimits the header from the body removed)

—
Reply to this email directly or view it on GitHub
#4 (comment).

[tomponline]

I know what you mean :)

The err return value shouldn't be affected by this change, as the "-ERR" bit you look for is still in the response body of the API command not the headers. I was concerned that would be a problem too.

[danbogos]

Yes from that perspective not but ReadEvents receives another response ....

DanB.
Am 14.06.2014 11:53 schrieb "TomP" notifications@github.com:

I know what you mean :)

The err return value shouldn't be affected by this change, as the "-ERR"
bit you look for is still in the response body of the API command not the
headers. I was concerned that would be a problem too.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[tomponline]

I'm not following, sorry. ReadEvents will still decode the header via readEvent, so the next event on the socket should not be affected. This PR just throws away the header as AFAIK it only contains the content-length when sending API responses from Freeswitch. For the other types of responses; dispatchEvent and command reply, the headers are not sent back to the calling function. Cheers

[danbogos]

Thanks Tom,

Merged it now.

Was on the way today morning and imagining dispatchEvent will get the
part with header/body so I see now the patch makes sense.
Btw, out of curiosity, are you using fsock in any serious project or
just testing?

DanB

On 14.06.2014 12:12, TomP wrote:

I'm not following, sorry. ReadEvents will still decode the header via
readEvent, so the next event on the socket should not be affected.
This PR just throws away the header as AFAIK it only contains the
content-length when sending API responses from Freeswitch. For the
other types of responses; dispatchEvent and command reply, the headers
are not sent back to the calling function. Cheers

—
Reply to this email directly or view it on GitHub
#4 (comment).

[tomponline]

Thanks Dan. Yes we are using this for the company I work for. We are using it to control outbound calls from a PBX server and will in the future use it to control 'call backs' initiated from a web site.

A few years ago I wrote a similar library to fsock in PHP, but for this project we wanted to use something with more concurrency in the language - hence Go and fsock.

We use the hash API in Freeswitch to set a global variable that assigns new calls to a particular fsock client process ID.

That way when a process starts up it effectively 'registers' with Freeswitch by setting its PID into the global hash key. Then when a new call arrives the dialplan extracts this value and sets it into the call's channel variables.

Each fsock client then subscribes to channel events containing a channel var of its PID - so that it gets all events for the calls its responsible for.

[danbogos]

Hey Tom,

Interesting mechanism, might use ideas out of it if requirements show up
here ;).

Btw, what is the reason you would like to have your requests being
balances around more fsock connections?

DanB

On 16.06.2014 10:42, TomP wrote:

Thanks Dan. Yes we are using this for the company I work for. We are
using it to control outbound calls from a PBX server and will in the
future use it to control 'call backs' initiated from a web site.

A few years ago I wrote a similar library to fsock in PHP, but for
this project we wanted to use something with more concurrency in the
language - hence Go and fsock.

We use the hash API in Freeswitch to set a global variable that
assigns new calls to a particular fsock client process ID.

That way when a process starts up it effectively 'registers' with
Freeswitch by setting its PID into the global hash key. Then when a
new call arrives the dialplan extracts this value and sets it into the
call's channel variables.

Each fsock client then subscribes to channel events containing a
channel var of its PID - so that it gets all events for the calls its
responsible for.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[tomponline]

Yeah it works pretty well. We don't really load balance the fsock clients - its more that we have one active process that keeps tabs on how the calls are progressing, and then when we need to do a code rollout the active process stops accepting new calls after the a new process starts up and takes new calls (by overwriting the global hash variable with its PID). That way we can gracefully rollout new code without transferring call state.