HTML etc crashes program when no internet connection present

[Joshua Flynn]

There are different approaches (depending on how your program works):
- non-blocking sockets (why can't you use them?)
- stop to wait and consider the data complete after a given timeout
- finding how the protocol encodes the end of data -- I'm sure it does

Explicitely encoding the end of data (or the total size to receive) is the only reliable way to know when to stop receiving with TCP (if the server doesn't close the connection when finished, like with HTTP), so almost all protocols do it.

- SFML doesn't work with them, remember? And even with the hacky fix I made, I couldn't get recv to work with it.
- There's no way to know if the data is complete. If, say, I query 256 worth of data, and assume if I get 256's worth back, there's yet more to be received, what happens when there is strictly 256 worth of data on the stream? As unlikely as it sounds, it's not worth risking it, as if it's precisely 256 worth, it'd block.
- This may be possible, except the CRLF 'ending' is present in all the data streams at points where it isn't explicitly the end.

[Laurent]

- SFML doesn't work with them, remember?

No. For me they work perfectly, except connect() but you don't need a non-blocking connect here.

- There's no way to know if the data is complete. If, say, I query 256 worth of data, and assume if I get 256's worth back, there's yet more to be received, what happens when there is strictly 256 worth of data on the stream? As unlikely as it sounds, it's not worth risking it, as if it's precisely 256 worth, it'd block.

That's why I said: use a timeout -- which means: if it waits for too long then it probably means that there's no more data to receive.

- This may be possible, except the CRLF 'ending' is present in all the data streams at points where it isn't explicitly the end.

If CRLF is a valid sequence that can appear in the middle, then the end is probably a double CRLF. Anyway, have you read carefully the specification of the protocol?

[Joshua Flynn]

No. For me they work perfectly, except connect() but you don't need a non-blocking connect here.

Inverse for me. Connect works, but recv doesn't.

That's why I said: use a timeout -- which means: if it waits for too long then it probably means that there's no more data to receive.

Timeout might be worth trying, but doesn't that force receive into non-blocking mode... (see above... hehe).

If CRLF is a valid sequence that can appear in the middle, then the end is probably a double CRLF. Anyway, have you read carefully the specification of the protocol?

IMAP's FETCH <ID> BODY[TEXT] returns the text verbatim. The last command when sending an email in sockets is the return or \r\n (CRLF) command. SMTP specifies a CRLF with a dot and another CRLF, but this gets removed from the body of the text. The only way for me to be able to tell the end presently is if it matches the server return response, but it's risky - because if the text body contains the same response, it would end prematurely, and if the server doesn't return the same response, it won't end at all.

I'll try a timeout variant but I'm not holding my hopes out.

[Laurent]

Inverse for me. Connect works, but recv doesn't

So please report it in a new thread, with detailed explanation and a complete and minimal example that reproduces the problem

Timeout might be worth trying, but doesn't that force receive into non-blocking mode... (see above... hehe).

A "receive with timeout" function is explained in the "selector" tutorial.

[Joshua Flynn]

So please report it in a new thread, with detailed explanation and a complete and minimal example that reproduces the problem

I don't think the problem is with SFML, it's just that either the IMAP or the SMTP servers don't respond in a timely manner. I would need to look into it further before I could say either way, but I just want to get the email program finished first.

A "receive with timeout" function is explained in the "selector" tutorial.

This seems like the most useful solution to the problem.

[Joshua Flynn]

A "receive with timeout" function is explained in the "selector" tutorial.

Worked, thank you!

[Joshua Flynn]

I wanted to ask, in 1.6's Http class's SendRequest, it has a timeout function.

Given it only returns a Http::Page type, how does it indicate timeout occurred? (This is assuming it's the same Http class that previously succeeded in using a SendRequest, and this time times out).

[Laurent]

It will return sf::Http::ConnectionFailed.

[Joshua Flynn]

Thank you.

[Joshua Flynn]

For some reason, in 1.6, when using sf::Http class' 'SendRequest' function in my program, after a while of numerous calls to SendRequest (we're talking once every 4 minutes and 30 seconds for hours at a time), SendRequest, even with a timeout defined, still hangs.

It'd be impossible for me to supply a 'functional snippet' as I've built numerous low level classes to form a series of upper level classes, but I know this - as my program prints out statements, I know it hangs at either 'DownloadPage' (basically a call to Http.SendRequest), or .GetPage().GetStatus() (again, which is basically GetStatus for a Http::Response). Seeing as GetStatus shouldn't do anything but inquire with data in memory, the only thing I can determinate is SendRequest itself is hanging during either the send or receive phase - as it acts suspiciously like blocking. Setting a timeout value has no apparent effect.

[Laurent]

SFML 1.6 is already dead (which means: I won't fix anything), you should test with SFML 2 instead.