#154636 - irq - Sat Apr 19, 2008 4:52 pm
I was told that, while not explicitly blocking for incoming data with dswifi, any received data would be dropped (e.g. data sent while doing other things, recv() called afterwards, recv() blocks until it gets other data). Assuming that there is no way to predict when messages will be received, or their length, and that every new message is parsed and acted upon (parsed, maybe do something on-screen, etc.) for a long enough period of time for new data to be sent, is there a way to ensure following calls (recv and whatnot) catch data sent when not blocking?
I also read that dswifi was (or parts of it were) planned to be rewritten in the near future, so would it be worth waiting for that?
Thanks.
Last edited by irq on Sat Apr 19, 2008 11:04 pm; edited 1 time in total
#154649 - josath - Sat Apr 19, 2008 8:51 pm
| irq wrote: |
| I was told that, while not explicitly blocking for incoming data with dswifi, any received data would be dropped |
You were told incorrectly.
#154656 - irq - Sat Apr 19, 2008 11:04 pm
| josath wrote: |
| irq wrote: | | I was told that, while not explicitly blocking for incoming data with dswifi, any received data would be dropped |
You were told incorrectly. |
Alright, thank you very much. Problem solved.
#161467 - Smiths - Mon Aug 04, 2008 4:52 pm
not to dig up an old topic, but how was this solved?
#161468 - josath - Mon Aug 04, 2008 5:00 pm
Basically all you need to do is keep calling recv() every so often and you'll get all the data. Can you explain in more detail what problem you are having exactly?
#161801 - Smiths - Thu Aug 14, 2008 5:33 pm
my loop is the recv and it just seems to randomly stall. but then it randomly works.
there's no rhyme or reason to it.
it's downloading a 950KB file so really the stalls are killing the whole process.
Debugging shows it's just receiving such a minor amount of data that it doesn't consider the recv function done.
| Code: |
for(int r; (r = recv(my_socket, incoming_buffer, RECEIVE_SIZE - 1, 0)) > 0; )
{
incoming_buffer[r] = 0;
buffer = incoming_buffer;
....... stuff with buffer .....
}
|
i have cancel routines in (press B to cancel) but it won't even acknowledge a button press. it's like it's just trickling waiting for the data
RECEIVE-SIZE is 4096 for this. that was the most stable.
#161802 - elhobbs - Thu Aug 14, 2008 6:13 pm
recv does not wait to return data that fills the receive buffer size. it will return up to the receive buffer size in a single call. if it is nonblocking it will return immediately if there is no data. if it is blocking it will wait until there is some data, but it will not wait for the buffer to fill.
can you give a little more detail as to what this means? | Quote: |
Debugging shows it's just receiving such a minor amount of data that it doesn't consider the recv function done.
|
are you debugging the dswifi library?
#161810 - Smiths - Thu Aug 14, 2008 8:40 pm
i meant simple debugging.. just drawing output each time a loop goes.
when it "stalls" it simply took a lot longer for a tiny bit of data to pass.
the blocking/nonblocking i have heard/read about... but got easily confused unfortunately.
#161816 - elhobbs - Thu Aug 14, 2008 9:29 pm
blocking is the default mode. in the case of recv it means that if you call recv and there is no data ready to be read then it will wait until there is data - in other words recv will not return until there is data, an error occurs or the socket is disconnected. if the socket is set to non-blocking then recv will return immediately without waiting if there is no data ready to be read.
edit: you may have a problem with your send code. if you are sending very small amounts of data each time you may be running into an issue with a feature of TCP/IP where small sends are buffered together - NAGLE or something like that. if that is the case then you can get delays using TCP/IP. it is possible to disable it on a pc but dswifi does not support it AFAIK.
#161852 - Smiths - Fri Aug 15, 2008 5:20 pm
it's still not "fixed" persay but i did go all non-blocking and all fdset blahblah on it so i think it's more efficient. now the best part is.. 900KB i get the bad_alloc error
so i now don't believe remotely it's the wifi stuff... it's the AceKard menu.
hooray.. more debugging.
thanks for help too. really appreciated.
#161853 - josath - Fri Aug 15, 2008 5:36 pm
"bad_alloc error" sounds like you ran out of memory.
#161863 - elhobbs - Fri Aug 15, 2008 9:38 pm
can this happen on malloc(0)?
#161865 - josath - Fri Aug 15, 2008 9:43 pm
malloc(0) doesn't make any sense to me. allocate zero bytes of memory? it's like printf(""); or something, what's the point?
#161883 - Smiths - Sat Aug 16, 2008 9:42 pm
it was 100% a memory error. we pushed the AceKard RPG to the limits of available memory and it was just running out.
I took the whole routine and made a standalone program using the AceKard gui functions for displaying messageboxes,etc.only and it's working fine, even when downloading a 1.3MB file and extracting the 8MB file inside of it.
and for the downloading, I am now using non-blocking and select() routines, so i figure at least if anything it's now more efficient.