Can we have some more information on the structure of this table?

There is an old post from A1k0n but it actually fails to document it's functionality properly, and he even calls functions in his own code that he didn't document.

Current issues that plague TCP plugins include a very long timeout when attempting to connect.. and in these cases, it is not actually reaching out to a perfectly functioning tcp server at all.

Attempts to set a timeout and then connect again do not actually resolve this because it appears the previous connect attempt (which hasn't timed out) is still sitting in queue and cannot be removed... resulting in multiple connections to the same server... and multiple callback triggers with no apparent way to determine which of the connections is actually calling back or for that matter, preventing multiples anyway.

Also the undocumented Disconnect() function does not actually always disconnect and has been the source of frustration for some people as well.

Furthermore the wealth of code originally written by a1k0n is lost and the links to it are dead. We only have a few old copies in different states of decay floating around.

the link to a1k0n's original post https://vendetta-online.com/x/msgboard/16/17247

So, it was relatively trivial for me to recover the old code-samples that Andy put online (since I personally hosted them) and make them available here.

However, on the "broader request" of this thread, I'm going to defer for now, until we can come back around to working on the client.

Because, fundamentally, there are going to be plugin-facing lua API changes in the VO client. We're probably moving to a different interpreter, which is inherently going to change some things, and there's also some restructuring that will likely happen.

But, I don't have a timeframe for this right now, because.. well, we didn't expect to spend two months fixing major server-side problems that we rather-suddenly became aware of (thanks to the magic of intensive testing).

Thank you for finding that code.. and oh dear is it quite a bit more than the copy I have :/

... here's to resisting asking another question or two after you have "deferred"..lol

here also is my +1000 upvote to the idea that TCP might be a little cleaner after an interpreter upgrade

... here's to resisting asking another question or two after you have "deferred"..lol

Look, you're welcome to raise issues around the Lua API and questions you'd like to have addressed that are directly related to the OP topic.

You may not receive an answer in the immediate-term, particularly if that API is going to change. But still, having the question, or raising the particular concern, will still give us guidance about what issues are impacting people that they wish would be improved, etc.

Granted, stick to the "one Suggestion per thread" kind of thing, so don't stray off the TCP socket area, but still, you can make related notes/questions around that, and we'll come back around to that when we can.

Just some documentation on the TCPSocket table would be helpful, since we can't see what methods or fields are available in it. This could help us do things like sub-classing so that individual raw sockets that are receiving async callbacks could be tracked and identified and their buffers managed individually.

Right now I can't seem to tell if calling Connect() is generating a new socket and if so, how to keep track of or ignore the previous socket who's connect() method hasn't timed out after a good 4 minutes or whatever it's set too (is this changeable?).

Andy's documents suggest that local sock = TCPSocket() creates a table to a unique socket but this doesn't seem right??

I see in his code:

local conn = {tcp=TCPSocket()}
SetupLineInputHandlers(conn, conn_handler, line_handler, disconn_handler)
local success,err = conn.tcp:Connect(host, port)

but on the last line, what is the "success" and "err" represent here? Is this a clue that the Connect() method is generating the socket and not TCPSocket()... such that "success" means a socket was created but not yet connected (async)?

I find this socket thing very confusing and can't seem to grasp what is actually supposed to be happening here in terms of raw sockets.

Before you don't :Connect or :Listen nothing will happen, the rest is to set everything up first.

looks like Connect puts the initial packet in queue and TCPSocket() just binds the port... it would be nice to be able to SETTIMEOUT on the socket wrather than having to delete the socket and make another if it is taking too long... the current TIMEOUT under the hood is like 3 or 4 minutes long..

That being said.. I have now a re-written version of Andy's socket layer that provides a few more hooks and builtin reconnect timer.. though for the initial connect call it just waits until it timesout or connects

you can view progress on it here: https://github.com/haxmeister/TCP/blob/main/TCP/client.lua

though it is not yet released and the readme and wiki need to be updated... when it is complete and all that is done, I will make an official release and probably put it on voupr or something

right now it provides hooks for:

onMessage
onDisconnect
onConnect
onReconnect
onGiveup
onFail

and I'm considering an option for having it spit default messages to secondaryHUD automatically for each of those callbacks, so you don't have to use all of them in your plugin code to watch connection messages.. not that you need to