On Sat, 22 Feb 2014 22:41:24 GMT, punkUser wrote:
Bit of a necro, but I'm doing something similar but ran into a few issues and am looking for advice.
In my case I'm proxying two connections as above, but both come in from listen sockets and thus have their own fibers. It would seem natural to use the two fibers for the two proxying directions, but I'm not sure how to most cleanly get the TCPConnection objects passed between the two.
I also had this same questioning a while back for websockets. I wanted to connect two peers together to exchange messages. The ideal solution is to think tasks rather than sockets. Each socket is open in one task, and your task can exchange data with other tasks which, in turn, can write to sockets.
Thus, you'd have to create a global/static Task[string] aa that your connections mutually know about, and then you can use vibe.core.concurrency to Task.send and Task.receive. While you're waiting for information with Task.receive, there's yielding going on so as long as you loop through it you should be good to keep the socket ownership.
e.g.
Task[string] aa;
someConnection(HTTPServerRequest req, HTTPServerResponse res){
string tmp;
while(tmp = aa[req.params.peerId].receive!String)
res.write(tmp);
}
This is an HTTP request/response for simplification, but for raw tcp the socket read/write and task send/receive methods would work the same. Just think as tasks like processes and send/receive as IPC. Also, you should take a look at this book which helped me understand these concepts more easily (internally vibe is very kernel-like!)
http://books.google.ca/books?id=RzP3iH0BSW0C&lpg=PA99&ots=mpcCbSzUY_&dq=real-time%20concepts%20for%20embedded%20systems%20task%20message%20queue&pg=PA68#v=onepage&q&f=false
- "real-time concepts for embedded systems" p.97