there HAS to be something else going on that we cant see
I cant get several Mb/sec with sockets
The DB driver I wrote relies on sockets all event driven and they worked for a publishing system which moved tons of data through them
Were they as fast as the ones written in C++ ? No but thye were a damn sigh easier to deal with as various OS updates came along
Same I have done a ton with Xojo Sockets and I never had show stopping socket performance issues. MBS was a bit faster since they wrap Lib2SSH client. Can you post your code @Meestor_X?
I did earlier in the thread. I first tried it with the normal DataAvailable events, then, just to see, tried it with a synchronous loop.
There’s nothing to it. Read input, write to output. Lather, rinse, repeat.
Super-slow on Xojo, instantaneous on .NET.
Could this be a socket configuration issue (size of buffers etc…)?
Maybe Xojo is initialising the sockets with different defaults to the .NET sockets.
From what I can remember, the MBS plugins have functions that allow some configuration of the Xojo sockets so it might be worthwhile experimenting with those.
I had already tried the .Flush (due to a bug in MacOS where the Socket will stop sending after a while if the GUI is not updated), it made no difference.
I have tried reducing the size of the packets, which are each less than 1kb anyway. No change. (No such manipulation necessary on .NET)
If you remove the hardware reads/writes does it speed up significantly i.e. is the slow down to/from the editor and/or to/from the hardware?
Have you wireshark’d things to see where the delay is?
Xojo.Net.TCPSockets is weird on 2019r1.1. Seems like it’s “kinda” there…
The LR shows it as available, the autocomplete shows it as available, with all its properties and methods, but it’s not there as a Super and I get all kinds of errors trying to add them to the project.
Can’t add it as an object and then change the super, as the LR indicates. Like I say, it’s very weird the way it “sort of” exists…
It’s just another step in the process of narrowing down the variables to try and figure out the cause, e.g. is it a xojo<>hardware issue or a xojo<>xojo issue.
Fair enough. I do appreciate all the suggestions! Norm and I are scratching our heads on this one!
I’m going to see if I can figure out an MBS socket. Stuck at the moment on how to make one “Listen”… MBS is VERY different from a TCPSocket so I’m not having much luck plugging one in in place of the other…
I’ll keep plugging at it.
If there’s any MBS experts here, maybe someone can help me figure out how to do the equivalent of:
myTCPSocket.Port = 50000
myTCPSocket.Listen
RawSocketMBS doesn’t have a connected event, or an .IsConnected property, so how do I know when the Socket has connected?
II can confirm that even after screen sharing the apps are dead simple and using either the event driven async or fully synchronous set ups they are dog slow and I’ll be damned if I can see why
The synchronous one did get swapped to use Socket.Poll instead of doevents since DoEvents in GUI’s can have weird side effects (it starts yet another instance of the event lop basically and that can be horrible)
But even the switch to using the events didnt suddenly make issues go away nor a ton faster
Ok, through trial and error I finally figured out how RawSocketMBS work, and the additional steps needed to create a listener.
Initial testing shows it completes the sync in 1:43, so it’s only 3x slower than Direct connection or via .NET, but that’s a heck of a lot faster than the Xojo TCPSockets!
Perhaps with some tweaking of parameters I can speed that up?
Anyone know how to tell what parameters I should try adjusting on the RawSocketMBS?