Okay. I'm having a weird problem with socket_recv.
49/50 times it's working great as long as the socket doesn't time out as it does sometimes, but that 50th time it will return a len of -1 which could indicate several things
Code:
// native socket_recv(_socket, _data[], _length);
static cell AMX_NATIVE_CALL socket_recv
(AMX *amx, cell *params
) /* 2 param */
{
int socket = params
[1];
int length = params
[3];
int tmp =
-1;
// First we dynamicly allocate a block of heap memory for recieving our data
char *tmpchar =
new char
[length
];
if(tmpchar ==
NULL) return -1;
// If we didn't got a block, we have to quit here to avoid sigsegv
// And set it all to 0, because the memory could contain old trash
memset
(tmpchar,
0, length
);
// Now we recieve
tmp = recv
(socket, tmpchar, length
-1,
0);
if (tmp == -1)
{
delete [] tmpchar;
return -1;
}
// And put a copy of our recieved data into amx's string
tmpchar
[tmp
]=
'\0';
int nlen =
0;
//int max = params[3];
int
max = length
-1;
const char* src = tmpchar;
cell* dest = MF_GetAmxAddr
(amx,params
[2]);
while(max--&&nlen<tmp
){
*dest++ =
(cell
)*src++;
nlen++;
}
*dest =
0;
// And we need to free up the space to avoid wasting memory
delete
[] tmpchar;
// And finnally, return the what recv returnd
return tmp;
}
Unfortunately all problems returns with the same error of -1. Tomorrow I'll reinstall VC++ and debug it deeper to find out exactly which of the returns are causing it.
EDIT: I've narrowed it down to the highlighted part.
When socket_recv() returned -1 I thought... That's fine. There probably was no data in that packet, it'll be in the next. But even though socket_change() returns true on every call, socket_recv() seems to get stuck in an enldess loop of returning -1.
Here's an example of the output when it's working:
Code:
Downloading http://checkip.dyndns.org/
Working
Working
Change!
Len: 259/2048
*My public server IP is printed here after parsing that text*
"Working" is whenever the worker "thread" is called.
"Change!" is after socket_change() returns true.
"Len: X" is right after socket_recv().
And here it is failing:
Code:
Downloading http://checkip.dyndns.org/
Working
Working
Change!
Len: -1/2048
Working
Change!
Len: -1/2048
Working
Change!
Len: -1/2048
Working
Change!
Len: -1/2048
Working
Change!
Len: -1/2048
Working
Change!
Len: -1/2048
Working
Change!
Len: -1/2048
And it goes on until I shut down the server.
Could the server be the failing link? Could it be a bug in the source? Could it be a problem with my hardware/software? Can anyone else reproduce it?
Here is the calling plugin, I will upload http2.sma as an attachment because it's too big to print out. I'll print out the relevant part.
Code:
#include <amxmodx>
#include <regex>
native HTTP2_AddToQue(...);
native HTTP2_getData(...);
new gIP[16];
public plugin_init() {
register_plugin("Test Plugin 1", "", "[ --{-@ ]");
server_print("Que: %d", HTTP2_AddToQue("http://checkip.dyndns.org/", "", "Complete", "QueryPublicIP"));
}
public plugin_natives()
register_native("get_public_ip", "nativePublicIP");
public nativePublicIP() {
if ( ! gIP[0] )
return 0;
set_string(1, gIP, get_param(2));
return 1;
}
public QueryPublicIP(Index) {
new data[256], temp;
HTTP2_getData(data, charsmax(data), temp);
new Regex:hRegex = regex_match(data, "\d+\.\d+\.\d+\.\d+", temp, "", 0);
if ( hRegex >= REGEX_OK ) {
regex_substr(hRegex, 0, gIP, charsmax(gIP));
server_print("%s", gIP);
return 1;
}
return 0;
}
public Complete(Index, Error) {
server_print("Download %d terminated with the code of %d", Index, Error);
}
Code:
public DownloadThread(ent) {
server_print("Working");
// ...
if ( ! socket_change(gInformation[stIndex][_hSocket], 1000) )
continue;
server_print("Change!");
// ...
if ( ! ( gBufferLen = socket_recv(gInformation[stIndex][_hSocket], gDataBuffer, tempsize) ) ) {
TransferDone(stIndex, -3, true);
continue;
}
server_print("Len: %d/%d", gBufferLen, tempsize);
EDIT:
Nevermind. Seems to be an issue with the host.
I added WSAGetLastError() to get the error code and it returned 10054, which is this:
Code:
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.