Socket optimisation
BlitzMax Forums/BlitzMax Beginners Area/Socket optimisation
| ||
So I am using TCP sockets and currently I am doing it something like this:'---------SENDING------------ BankStream.WriteDouble(something) BankStream.WriteLine(somethingelse) Sock.Send(BankStream._bank._buf, BankStream._bank._size) '--------RECIEVING-------------- Local Buf:Byte[Sock.ReadAvail()] sock.Recv(Buf, sock.ReadAvail) BankStream.Write(Buf, sock.ReadAvail) BankStream.Seek(0) 'interpret Print BankStream.ReadDouble() Print Bankstream.ReadLine() Notice how I send off the whole message in one send() function, and same with receiving. I have a feeling that this is faster for the network put possible slower on the cpu because I am using the bank streams. The other way is simply this: '---------SENDING------------ SockStream.WriteDouble(something) SockStream.WriteLine(somethingelse) '--------RECIEVING-------------- Print SockStream.ReadDouble() Print Sockstream.ReadLine() What I want to know is this: is this any slower (..or faster) than my top method? |
| ||
| Doesn't you have to check the return value from Socket.Send, to see if there is still things left to send? If I remember correctly you should not send more than 512 bytes at a time. But that might be different on different platforms. But it looks like you are sending much less than that. :) I believe that the "other way" is faster, since the computers doesn't have to work with the banks. No middle hands, just the stuff and the internet tubes. |
| ||
| If I remember correctly you should not send more than 512 bytes at a time. But that might be different on different platforms. You shouldn't send LESS than 512 bits (64 bytes). There isn't really an upper limit to packet side since there's no way you can know the MTU (or congestion) of every device on the way to your destination (although a qualified guess would be a MTU of 1300 bytes).It depends on whether the SocketStream is buffered, or whether it simply sends off packets as they arrive. The buffered operation is clearly faster, since you're wasting much less bandwidth. (Sending a double for instance is only 4 bytes, the minimum frame size of an Ethernet frame is 64 bytes, I don't recall if the headers down through the TCP/IP stack add 60 bytes worth of overhead, but if they don't the Ethernet driver will automatically pad the frame before sending out on the interface). |
| ||
| Hello. If you use the code inside a bucle the creation of receiving buffer need free the bank after use it. Make you the send and receive buffer before the bucle and reuse it. If you not use bucle not need speed up the code. the time consumed is very small. Bye, Paposo |
| ||
| Flameduck, how come you shouldn't send less than 64 bytes? I always thought it didn't _really_ matter, and just stuck by the rule "if you can send less packets without screwing anything up, do it.". Also I think that I'm going to use my first method now anyway, especially for reading. I've found that reading everything into a buffer then reading out of that buffer causes a lot less problems than reading from a socket stream when something goes wrong. To be honest, using the banks in order to speed up the actual network stuff is a good trade-off... I think. |
| ||
| Flameduck, how come you shouldn't send less than 64 bytes? Because the Ethernet interface, will pad it to a 64 byte frame anyway, which is the smallest frame allowed on an Ethernet interface. |
   |