<phvse>
Hello! Is Pony development still strong? I'm interested in the language but I don't want to create a big project in a dead/dying language.
<SeanTAllen>
phvse: we are making regular, steady progress
<SeanTAllen>
you can see the release cadence and commit cadence in the github repo
<phvse>
The project I have in mind is an advanced TCP proxy. Is Pony built up enough for this? I've been looking at the stdlib and I copied the sample TCP project, but I want to do packet decoding and such.
tme11 has quit [Read error: Connection reset by peer]
brainpro1 is now known as brainproxy
tme11 has joined #ponylang
<SeanTAllen>
you get the rawb bytes phvse, you can do whatever you want with them.
<SeanTAllen>
if you need a lower level interface than what you get from a normal socket read, you have c-ffi handy and can use that to do what you want.
<SeanTAllen>
its hard to say more without knowing specifics
<phvse>
okay, that'll work
<phvse>
I want the connections to scale well, so would making an actor to handle each connection be a good idea?
<SeanTAllen>
that is how you would want to do it, yes. per actor overhead is low.
<phvse>
okay perfect
<phvse>
So I'm thinking of having a class called ClientReceiver that extends TCPConnectionNotify and holds a map from TCPConnections to "Proxies" (the actor that manages the packets)
<SeanTAllen>
So there's a flaw in the Actor/Notify pattern that currently exists that we are trying to figure out how to address (so far, no luck, best idea can't always prove safeness).
<SeanTAllen>
So...
<SeanTAllen>
if those connections need to be added dynamically, there's no way to do that
<SeanTAllen>
because you can communicate with the enclosing TCPConnection but not the TCPConnectionNotify
<SeanTAllen>
so, you might need to "fork" TCPConnection into your own version and add behaviors that you need in order to add new proxies to the notify.
<SeanTAllen>
We hope to address this eventually but so far, as I said, our best idea didint turn out to always be concurrency safe.
<SeanTAllen>
phvse ^
<phvse>
I was thinking that the TCPConnectionNotify would check the address from the TCPConnection in TCPConnectionNotify#received and then send the `data: Array[U8]` to the actor in the map
<phvse>
oh and the proxy actor would need to send data back to the client connection
<phvse>
SeanTAllen ^
<SeanTAllen>
the way you could do it is have an actor that acrs as a router between things and can get new maps additions sent to it. that would work, but there's the overhead of an extra hop.
<SeanTAllen>
anyway, its all doable and you'll see once you start and can decide which approach is right for you
<phvse>
couldn't I have my class that extends TCPConnectionNotify be the router?
<SeanTAllen>
no
<SeanTAllen>
you wont be able to add new connections to it dynamically
<SeanTAllen>
TCPConnection provides no way for other actors to communicate with the TCPConnectionNotify
dipin has quit [Quit: dipin]
<phvse>
I don't think the actors would need to communicate with the TCPConnectionNotify though
<phvse>
only from TCPConnectionNotify to the proxy actors
<SeanTAllen>
ok
<SeanTAllen>
then that will work
<SeanTAllen>
how will the TCPConnectionNotify know about the proxy actors?
<SeanTAllen>
thats the big question you'll need to figure out
<SeanTAllen>
but, i am off to bed. ttyl.
endformationage has quit [Quit: WeeChat 1.9.1]
khan has joined #ponylang
<phvse>
`couldn't find 'has_next' in 'Array'` well that's annoying
<phvse>
okay .values() exists
<phvse>
hmm now I want to print out a u8 in hexadecimal
<phvse>
oh well I can't have one TCPConnectionNotify router because TCPListenNotify#connected expects an ios^ (which I believe means it can't be bound to a variable, and thus must be created in the method)
<qweo>
phvse: would your project be open-source?
PrsPrsBK has quit [Quit: PrsPrsBK]
<dave24>
phvse: It can still be bound to a variable, as long as you either (a) no longer use it after returning it from `connected` (either the variable goes out of scope or you assign something else to it) or (b) the variable holds only a tag.
<dave24>
However it is true that you cannot reuse a TCPConnectionNotify for multiple connections, since it is iso and exactly one must exist per connections.
<dave24>
s/connections/connection
PrsPrsBK has joined #ponylang
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
dipin has joined #ponylang
khan has quit [Remote host closed the connection]
dipin has quit [Quit: dipin]
aturley has quit [Read error: Connection reset by peer]
aturley has joined #ponylang
_andre has joined #ponylang
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
xllndr|wrk has quit [Quit: Leaving]
aurielmp[m] has joined #ponylang
endformationage has joined #ponylang
dipin has joined #ponylang
ExtraCrispy has joined #ponylang
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
alxs has joined #ponylang
alxs has quit [Ping timeout: 256 seconds]
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
user10032 has joined #ponylang
brainpro1 has joined #ponylang
brainproxy has quit [Ping timeout: 240 seconds]
alxs has joined #ponylang
<phvse>
qweo: it will be open source, yes
<phvse>
dave24: So I have the TCPListenNotify spawn a new TCPConnectionNotify which spawns a new Proxy actor? The middle man doesn't seem useful.
<phvse>
wait what if I made the TCPConnectionNotify the Proxy actor?
<phvse>
Will there always be one TCPConnectionNotify per connection?
<SeanTAllen>
phvse: you don't spawn a TCPConnectionNotify
<phvse>
well it needs to "create" one
<SeanTAllen>
And actor of type TCPConnection is spawned and you provide a class that implements TCPConnectionNotify to specialize it
<SeanTAllen>
I don't know what "it" and "one" refer to
<qweo>
phvse: post a link to a repo or something when you're ready please
<phvse>
TCPListenNotify needs to create a TCPConnectionNotify
<SeanTAllen>
No
<SeanTAllen>
Can you explain how you think it works?
<SeanTAllen>
Then I can correct where you are going astray?
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
<phvse>
Well I (think I) want one TCPConnectionNotify to delegate connections to the Proxies. I currently have a TCPConnectionNotify field inside my TCPListenNotify, but TCPListenNotify#connected expects a TCPConnectionNotify iso^and I'm having trouble returning the TCPConnectionNotify field in the function
<SeanTAllen>
can you step back and explain what you think the relationship between TCPConnection and TCPConnection is?
<SeanTAllen>
Also have you looked at the echo server example?
<phvse>
I got the example running but I'm failing to see why a TCPConnectionNotify is needed
<SeanTAllen>
have you read the documentation for TCPConnectionNotify?
<phvse>
(The names for these classes are a little confusing too. Is it a notification or a notifier or a notification handler?)
<phvse>
the docs say "Notifications for TCP connections."
alxs has joined #ponylang
<phvse>
which is somewhat vague
<phvse>
I've got every page open trying to figure it out
<SeanTAllen>
ok good to know
<SeanTAllen>
that needs to be improved
<SeanTAllen>
so
<SeanTAllen>
in Pony the "Notify" classes are how you can specialize an actor
<SeanTAllen>
so for example
<SeanTAllen>
TCPConnection contains all the generic tcp handling logic
<SeanTAllen>
but at key points in the lifecycle, you will want to specialize
<SeanTAllen>
for example, when connnected, when data is received, when data is sent, when the connection is closed
<SeanTAllen>
does that make sense?
<phvse>
So it's like a wrapper-handler-thing around TCPConnection that is called when certain actions happen?
<SeanTAllen>
no
<SeanTAllen>
other way around
<SeanTAllen>
a TCPConnection has a TCPConnectionNotify
<SeanTAllen>
there's a _notify field on TCPConnection
<SeanTAllen>
do the "outgoing connections" send information back on the "incoming connection"?
<phvse>
yes, the servers and client will be communicating with each other
<SeanTAllen>
ok
<SeanTAllen>
so what i was telling you wasnt correct
<SeanTAllen>
sorry
<phvse>
they'll be sending packets back in forth
<SeanTAllen>
when you get a new incoming connection, does it only proxt to one server? or is this like a chat room and they are all sending to each other?
<phvse>
and I might need to modify the packets and/or create new packets to send
<phvse>
yes it's only connected to one server
<phvse>
and then it will transition to other servers without disconnecting
<SeanTAllen>
sorry, i didnt understand that
<phvse>
my b for not explaining it properly
<SeanTAllen>
theres a list of ips to proxy to
<SeanTAllen>
but you only proxy to one?
<phvse>
yes
<SeanTAllen>
how do you decide which one of the ips to proxy to?
<phvse>
the client joins the game, the proxy defaults to whatever ip is set as the default in the configuration, the client sends certain packets telling the proxy that it wants to travel to a different server, the proxy closes the connection with the server and opens a new one with the server specified
<SeanTAllen>
ah ok
<SeanTAllen>
how does the client know about the different servers?
<phvse>
it'll request the server by name and the proxy will have a map from name to ip
<SeanTAllen>
ah ok
<SeanTAllen>
so things we need... a map from server to ip
<SeanTAllen>
then we open a connection for that
<SeanTAllen>
so...
<SeanTAllen>
lets see
<SeanTAllen>
ok, one more question...
<SeanTAllen>
how much load are you planning on handling? how important is latency in all this?
<phvse>
it should support 50,000 clients connecting to 10-20 servers
<phvse>
I'd say that's the maximum
<phvse>
latency should be minimum
<phvse>
I was thinking if Pony was too slow in modifying packets then I could write the packet handling in Rust and the networking in Pony
<SeanTAllen>
sorry need to step away for work
<phvse>
no prob
<SeanTAllen>
but the basics
<SeanTAllen>
your TCPConnectionNotify has a list of proxies from name to ip
<SeanTAllen>
when you get connectioned you create a new TCPConnection to the ip in question
<SeanTAllen>
when a command comes in to switch, you open a new connection to the new one
<SeanTAllen>
you need to store the connections in the TCPConnectionNotify
<SeanTAllen>
and can close the old one at the appropriate time
<SeanTAllen>
the outgoing TCPConnectionNotify would be supplied a reference to the TCPConnection that is incoming
<SeanTAllen>
and you can pass info back and forther
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]