TWX is using TClientSocket in non-blocking mode. What I saw in testing is that I was getting a WSAEWouldBlock error code, so I've added the appropriate code for the OnWrite event where I now resend the buffer. I wasn't checking the results of the Send function, and I'm kinda surprised this hasn't shown up before now. I'm adding the code to check the results (BytesSent) and update the Buffer appropriately. I have some testing to do, but I think this will fix the problem.

I'm glad you're enjoying this Rev. It's not often we mention sockets on this forum.

sockets seem simple at first, but the devil is in the details. there are tons of corner cases. for example, what is the right thing to do when you lose your network, or when your adapter's ip address changes? how do you detect those events in your code correctly (besides trapping socket errors)? also, what ip address should your listener socket use? if your machine has multiple network adapters, which one will route the traffic to the twgs? does it matter?

i recently hired two contractors to write some code for me at work. these guys were excellent C# developers with tons of experience. however, neither one of them had ever dealt with sockets outside of very high-level canned objects that took care of everything for them. they were completely lost when i told them they would have to construct udp packets from scratch and create sockets to send them. it took over a month for me to convince them that they should bind their listener socket to 0.0.0.0 and that was only after a serious intervention with the help of other team members.

@Singularity, SG just posted the latest version which includes an increased sockets buffer size. If you could test your scripts to see if that made a difference, I'd appreciate it. There appears to be an instability in this version and I'm looking for the cause, but hopefully you can still test this to see if I've improved anything.

I tested the wsend..





It's still skipping at/near the same spot. It's a quicker skip, but it's
still skipping.

Ok, I just verified that my test also fails on SG's server. That just shows how much this depends on characteristics of the sender, receiver and network. On a LAN I was able to see improvement with an increased buffer size, but over the network and with SG's server under load, the problem persists. I'll leave the buffer size where it is because it did improve things in my tests, but it's not going to mask this problem. I'd like to see if the efforts by Rev and EP have an effect. If their changes don't help, I'll know it's something I need to fix. For now, I'm not seeing any specific change I made to code that might have caused this to show up, but I did make some low-level changes like a new memory manager and new thread-processing system so maybe one of those changes is responsible. But again, I did see this behavior in v1.03 so it's not completely new, just more obvious. I'd also like to know if the problem shows up on any server or if it's something about SG's server.

I've rewritten TWX's TClientSocket Send command to detect imcomplete sends, buffer the unsent portion, and retry when the OnWrite event fires. I'm treating it all as a text string, where it might be more elegant as a buffer or stream, but I believe it will work properly now for these massive sends. Sing, I'd like to get you a build to test if you're willing.

Yeh, if you just want to put it up on the svn and send me the info again, I'll can build it and test it. A current build would be sweet.

It's on the svn: https://svn.twxscripts.com:8443/svn/mai ... y205/trunk
For read access: username is guest, no password.
Latest is revision 68.

Ok, compiled and attached. I get these 2 "hints" also...

[Pascal Hint] TCP.pas(585): H2164 Variable 'stream' is declared but never used in 'TModClient.Send'

[Pascal Hint] ScriptCmd.pas(1513): H2077 Value assigned to 'Delta' never used

Yeah, those hints won't affect things, but thanks. I'm interested if your huge sends succeed now. Let me know if you have a chance to test.

There's a popup "Unable to connect to ..." that comes up when the server can't connect. Can you disable that? It kills relog scripts.