Messages

1

Network / Massive Memory Leak

« on: February 03, 2009, 07:29:08 pm »

It is okay like that... I think everything is freed as it should be, but with a little delay...
But 50 MB is clearly way bigger than the data downloaded at once^^
But it is hard to tell if everything is freed because the program surely does not stop downloading...
But for this small project (the code is definitely a quite dirty hack) that I will mainly use for myself it is absolutely okay.

2

Network / Massive Memory Leak

« on: February 03, 2009, 03:42:29 pm »

There is a leak in heap memory, either in the classes Http or in one of the underlying classes. I am not using new or delete (despite for one single new/delete on begin/end of the program) in my program (downloading musics from lastfm), but it starts to use more and more heap space (memory field is heap). After ~200 MB of transferred data it uses ~40 MB ram (it begins with 2,2 MB)...
But I can't see where in the Http class it could be -.- all you use are C++-STL classes, I think.
I'll recheck my own code again and see if I can find a reason in there...

Ah:
I think I see now, it has most propably to do with the system cleaning up the memory allocated for the sockets or something similar, because the memory usage drops all of a shudden after reaching a high level (~50 MB) back down to ~6 MB. Seems very strange to me.

3

Feature requests / "GetConnectedAddress" function for SocketTCP

« on: January 26, 2009, 01:55:48 pm »

It should be fully portable to linux/windows in the form I posted...
getpeername has the same syntax on windows and linux (Berkeley sockets standard).
Please note that I changed the error-checking to == 0 instead of >= 0.

http://msdn.microsoft.com/en-us/library/ms738533.aspx
http://linux.die.net/man/2/getpeername

4

Feature requests / "GetConnectedAddress" function for SocketTCP

« on: January 21, 2009, 02:41:44 pm »

If connected, the function returns the IP address of the foreign host. If not, the returned IP is invalid. I know this can also be done by saving the IP of the foreign host on connection, but this can get quite hard - for example if you have an own (in my case cryptographic) session management in your server and don't have to (and don't want to) rely on a constant IP address for a client. The clients and the server are not keeping the connections alive - this is not possible for a server with possibly more than 1000 clients. You'll get in trouble updating the IP, make your storage for ips thread-safe and so on...

Code: [Select]



sf::IPAddress SocketTCP::GetConnectedAddress() const
{
if(IsValid())
{
sockaddr_in ipbuffer;
SocketHelper::LengthType len = static_cast<SocketHelper::LengthType>(sizeof(ipbuffer));

if(getpeername(mySocket,reinterpret_cast<sockaddr*>(&ipbuffer),&len) == 0)
return IPAddress(inet_ntoa(ipbuffer.sin_addr));
}
return IPAddress();
}



5

Network / Just another funny bug

« on: January 21, 2009, 12:20:22 pm »

Yes, but I like the solution with the flag best. It is easy to test if this flag is available and it doesn't take the user of the library the freedom to handle the signal himself...

6

Network / Alternative to whatismyip.org

« on: January 20, 2009, 11:39:18 pm »

Okay, great .

7

Network / Just another funny bug

« on: January 20, 2009, 11:38:25 pm »

Maybe this will help:

Linux.die.net:
When writing onto a connection-oriented socket that has been shut down (by the local or the remote end) SIGPIPE is sent to the writing process and EPIPE is returned. The signal is not sent when the write call specified the MSG_NOSIGNAL flag.

Maybe you should use this flag?

8

Network / Alternative to whatismyip.org

« on: January 20, 2009, 07:08:29 pm »

Thats not that good...
Okay. It is no possible alternative, I think

We have to find another way - whatismyip.org still does not respond. (It least I get stuck on creating a connection).

9

Network / Just another funny bug

« on: January 20, 2009, 06:48:01 pm »

Hey - I seem to be receiving a SIGPIPE from within SocketTCP::Send - it means that you try to write to a socket without a reader - the default reaction is to terminate the application.
This is what happens to my server if the client kills the connection before everything is ready. At first, a FIN packet is sent, but the server does not react to it properly. Then, when the server is trying to write again (because Send did not return Socket::Error but Socket::NotReady from within Send), it really sends the data (normal PSH packet), but all it gets is the RST packet from the obviously already closed client socket.
And then, the server process receives a "SIGPIPE" signal and is terminating.

I'm working with Non-Blocking sockets.

A possible workaround:
Add "signal(SIGPIPE,SIG_IGN);" to the SocketHelper initialisation for Linux.
I would also suggest to test the return value when you are sending the packet size in SocketTCP::Send(const sf::Packet&).

10

Feature requests / Add Timeout to "GetPublicAddress"

« on: January 18, 2009, 08:46:18 pm »

I GOT it.
Please add:

Code: [Select]


#if defined(EAGAIN) && EAGAIN != EWOULDBLOCK
    case EAGAIN: return Socket::NotReady;
#endif
#if defined(EINPROGRESS) && EINPROGRESS != EWOULDBLOCK && EINPROGRESS != EAGAIN
case EINPROGRESS: return Socket::NotReady;
#endif

to the switch-case in the Linux "SocketHelper.cpp" SocketHelper::GetErrorStatus()!
The error values are sometimes the same, but obviously not always.
connect sets errno to EINPROGRESS, in my case.
See:
http://linux.die.net/man/2/connect

The precompiler statements just make sure there are no double values in the switch case.

This also explains why it works perfectly on windows

Together with this one, all the other bugs vanished. Everything is working fine with these changes.

11

Feature requests / Add Timeout to "GetPublicAddress"

« on: January 18, 2009, 08:21:02 pm »

Yes, there is one thing I first considered a bug, which isn't, because there is an immediate return if the socket is non-blocking. But this one definitely is. If you try to connect with a blocking socket with timeout, and the connection is successfull on the first "connect" call, you will end up with a Non-Blocking socket.
Maybe this is simply not possible, connect succeeding on the first time, (who knows? I don't see any reason why it can't be possible), or it just appears on loopback or something like this...

You could replace:

Code: [Select]


 bool IsBlocking = myIsBlocking;
 if(IsBlocking)
        SetBlocking(false);
       
        if (connect(mySocket, reinterpret_cast<sockaddr*>(&SockAddr), sizeof(SockAddr)) >= 0)

        {

            // We got instantly connected! (it may no happen a lot...)

            return Socket::Done;

        }


by:

Code: [Select]


bool IsBlocking = myIsBlocking;

        if(IsBlocking)
        SetBlocking(false);
       
        if (connect(mySocket, reinterpret_cast<sockaddr*>(&SockAddr), sizeof(SockAddr)) >= 0)

        {

            // We got instantly connected! (it may no happen a lot...)
            if(IsBlocking)
            SetBlocking(true);
           

            return Socket::Done;

        }


I will do some bug research with the SocketTCP connect code... I will tell you if I know more about the return value thingy.

12

Feature requests / Add Timeout to "GetPublicAddress"

« on: January 18, 2009, 04:29:06 pm »

Hm, it does not really seem to work:
http://www.sfml-dev.org/forum/viewtopic.php?t=933

If I remove the timeout-parameter, it works.
I think this is related to a bug I posted, but there was no answer up to now - the return values of "Connect" are wrong. When its given a timeout, Connect returns 3 instead of Socket::Done, even if the connection has been built properly.

See:
http://www.sfml-dev.org/forum/viewtopic.php?t=883

I'm currently walking through the implementation of connect, but I don't see where in the connect call this bug arises.

There is at least one little bug:
If the connection is immediately successfull (Connect with timeout), you are not resetting the Blocking Mode to "true".
This might trigger a lot of funny bugs (especially with the loopback - it is very fast and so not unlikely the connection works "immediately").

13

Network / Alternative to whatismyip.org

« on: January 18, 2009, 03:55:06 pm »

Looking for an alternative to whatismyip.org (which is not reachable, at least from here)...

Code: [Select]


     sf::IPAddress __getIpFromCheckipdyndns_org()
    {
IPAddress PublicAddress;

Http Server("http://checkip.dyndns.org");
Http::Request Request(Http::Request::Get, "/");
Http::Response Page = Server.SendRequest(Request,4.f);

if(Page.GetStatus() == Http::Response::Ok)
{
string s = Page.GetBody();
size_t ind = s.find_first_of("0123456789");
if(ind != string::npos)
{
size_t indl = s.find_first_not_of("0123456789.",ind);
string sub = s.substr(ind,indl-ind);
if(sub.length() >= 7 && sub.length() <= 15)
{
PublicAddress = sub;
}
}
}
return PublicAddress;
}


Any idea why it is not working (the page is reachable in my Browser), but immediately returning an empty page??

14

Feature requests / Add Timeout to "GetPublicAddress"

« on: January 18, 2009, 12:59:06 pm »

Hey, that was really fast. Thanks.

15

Feature requests / Add Timeout to "GetPublicAddress"

« on: January 18, 2009, 01:22:45 am »

Problem:
The server at whatismyip.org is sometimes not responsive or does not answer our requests (for unknown reasons, though I only do a request once, when (re)starting the program).

Possible solution/workaround:
Add a way to pass a timeout value. If the connection to the server can not be created successfully, return an invalid IP.

Since you are using the HTTP class to connect by now, I would suggest to add a timeout in the HTTP/FTP class too. It is supported by the underlying sockets, so it shouldn't be to hard to implement...