Sockets, pull the plug
BlitzMax Forums/BlitzMax Programming/Sockets, pull the plug
| ||
| Guys (and girls :P) I wonder... i setup a stream for a socket and found it is blocking. Isn't that so? How did i find out? Count the game loops and it just stopped counting. Then i found another way using socket.Recv() which runs perfectly and the loop keeps counting. However if i keep flooding it with 4000 in lenght, text strings (=big packets) it seems to freeze at some point. Are there any alternatives besides these 2? I found there is as well only 2 options for sending bytes, that is using the either a stream, or the send() command. Am i right? I know whats arround in lib form, but im asking here for TCP using RAW sockets. Thanks. |
| ||
| Your probably overloading the buffer, using strings for packets isn't very efficient. |
| ||
| using strings for packets isn't very efficient your kidding? :P ye, so what i really want to find out what is blocking and what is non-blocking. Basicly by keeping it busy processing packets. |
| ||
| How many times per second do you send that ... don't forget, regular connections only have something between 12 kbyte and 50kbyte per second upstream ... this would mean 12.5 packets of that size per second, not per 50 milliseconds ^^ ie I would bet you just flood your whole buffer as already mentioned above. |
| ||
| lol, i was actualy just holding my send key down and. ok,so when a buffer gets flood it crashes? cant we resize the buffer? if its set to 4096 and we need lets say 5000? |
| ||
| The buffer is a hardware thing, not a software. And actually, a message can not be larger than 1492 / 1500 anyway ... I would suggest getting some "basic" documentation on TCP and UDP if you still are after the idea creating a networking layer that is capable of more than killing apps ^^ |
| ||
| ok,so when a buffer gets flood it crashes? cant we resize the buffer? if its set to 4096 and we need lets say 5000? you'll need to split it into multiple packets -- even if your test works with >1500 bytes, most switches and routers won't, so it has few real-world applications. Search for 'MTU' for more info (maximum transmission unit) |
| ||
| ok, well for my game i will not exceed that. I was just doing that on purpose. Nonetheless i will checkout that buffer limit anyway. Thanks |
| ||
| Thats why I suggested having a look at Vertex' BNetEx module. he put a lot of time in research this kind of information for all 3 plattforms. |
| ||
| ok, thank you, where can i find BNetEx? |
| ||
| http://vertex.dreamfall.at/bnet/bnetex170beta2.zip There you will find the current version. Alternatively, the current version can always be found on the blitzhelp.net modserver at www.blitzhelp.net/modserver but you will need to manually call bmk (or use an ide that supports it) to check out modules from there |
| ||
| thank you! |
| ||
| Vertex.BNetEx v1.70 Beta 2 Thats AWESOME! i check it out. Hey, do you know if this is blocking? Where can i find more info on this lib? I scrap my own, this one is really good. Is it still supported? |
| ||
| Yup, as far as I know vertex still is working on it. Don't know if it is blocking, you could have a simple look at the tcpstream implementation to see thought :) There is a thread on it but it won't help you much as it is in german. But if you build the documentations this should be more than enough I think. its quite simple and is wrapped into TStream extends so simple to handle. |
| ||
| vertex should really put a page up and add a donation button. |
| ||
| I am considering maybe using BNetEx except it could really do with English documentation and I'm not too sure I'm happy with the idea of a UDP `stream`. |
| ||
| I don't see how UDP can be reliable with a network game. I have used BNetEx for a chat client before, it's reliable (never done any stress tests though). |
| ||
| UDP alone obviously isn't reliable but you can add reliability by adding acknowledgments or something. |
| ||
| correct ... by readding the stuff the TCP protocol does on its own. But it is optional so you can selectively apply it to messages where you need it to have, not on stuff where it is not worth it. |
   |