Blitz's TCP idles very long before sending data...
Blitz3D Forums/Blitz3D Programming/Blitz's TCP idles very long before sending data...
| ||
| ever since i started programming with blitz TCP, i got the problem. my server sends a data package with 3 bytes in total and waits for the client to respond. but the client gets these 3 bytes delayed approximately 50 ms later, because the Blitz TCP engine is sending these bytes with a delay... which makes the whole app useless :( i think it's because TCP collects data until a packet of a certain size is full. this certain size seems to me more than 3 bytes... is there anyone who can help me? thanks. |
| ||
| Well, an obvious hack is to send a larger packet. |
| ||
| my packet is exactly 3 bytes. how large should i make it? does it depend on the router or is it a fixed size? but this just isn't it... a proper solution would be to just send it out using some sort of windows command, hmm? |
| ||
| Can you not use UDP? TCP has never really been for time critical applications... |
| ||
| i'm coding a multi-PC raytracer. so with UDP i get problems because once even one packet is missing, everything stops working... |
| ||
| Resend if the packet goes missing then. Tag each packet with an unique number. When your code on the other side receives a packet, then send back a confirmation packet. If the sending side doesn't receive a confirmation, resend the packet again. |
| ||
| i think tcp is fast enough and i don't want any UDP bugs here... there must be a function in some library to send the TCP packet without waiting until it's full... |
| ||
| As an Blitz3d TCP coder send 2004 i am looking into this.. i will prove every one wrong here as usual. by using my knowlage :) Stay tooned for my answare will come this wekend. |
| ||
| 1) hey why are you only sendind 3 bytes ? 2) if you dont have controll over flow blitzbasic TCPIP block your servercode if recivebuffer is over 8000 bytes. maby you can explain what you trying to do ? and maby UDP is the way here as we speak lan. |
| ||
| Hi Devils I think that the problem should be in the implementation of the blitz routine, or the routine that blitz call. I have some sort of TCP/IP communication between two machines connected directly via an ethernet cable, and I experienced the slow transit of information, but, has no time yet to research a solution. I think that Ethereal (or other sniffer) should help to analyze the problem, generating all sort of packet's with different length's on one machine and in another, or the same, running Ethereal to catch the packets for a while and then watch the way they arrived, trying to find if there are a better way of send small packets than other's. I read some.. and still learning: An ethernet frame must have at least 46 bytes of data to 1500. The overhead of an IP datagram is 20 bytes for it's header, and another 20 bytes for the TCP header, so the minimal TCP data should be 6 bytes: (20 + (20 + 6)) or the minimal TCP/IP that I think should be long enough to be sent over an ethernet lan. If a packet with less than 46 data bytes is to be sent, must be filled with zero's, until reach 46 bytes of data. On the other hand, the biggest TCP datagram that can be set with out fragmentation (to slice the data in two or more ip packets) is of 536 data bytes . In other words, if I have to decide when to sent a tcp packet over an ethernet lan, I choose to wait at least 6 bytes to 536. If I put in consideration the fact that, only 6 bytes of 72 (minimal ethernet packet) are data, so the overhead is 66 bytes, I probably wait some more bytes to do a better use of the bandwidth. And that's the problem I think we have, consequence of the implementation of the send routine. What I mean is, numbers with minimal amounts and maximum quantities are in each level of the stack, and I don't know which weight's more than others, so if some one has the answer: welcome!! I think both are in the same boat! best regards Juan |
| ||
| I have some experience with render farms... that can be a bitch even with industry standard software like maya.... What I would do is make your ray trace program... compile to an exe... and have that exe accept command like switches. The program you write would only analyze on one frame of the animation, or in a specific x,y + width, height section of the screen. Next I would write a listener application in blitz.. That has whatever tcp port open you want. Have a bit of a delay in the application, and exit the loop when called. So any one of the machines could throw a file out on a network share. Then run your program... It then blasts out the "run render" command to all of the machines. They would grab the file on the share you specified with the switch, and render its specific part. Also you would want to kill the listener application before it starts the render to improve speed. Then after the render is complete save the section or frame to that network share with a naming convention. Before closing the renderer start up the lister application again. In your program write an assembler that would take those named exported chucks and put them together however you like. Sounds lenghty but its rather quite simple. Also if you want them all in sync with one another and the above solution doenst work. Use Raknet... its amazing, and so easy to use. Dont bother coding UDP, let raknet handle it for you... you just send message headers and youre finished. |
   |