RejectedSoftware Forums

On Fri, 21 Dec 2012 00:21:25 GMT, punkUser wrote:

The Signal is usable in two ways:

1. The normal way, wait()ing for the signal to be emitted. Multiple fibers can wait (block) for the signal and all will continue when the singal is emitted.

Ok so this is effectively what a TcpConnection will do when I do a "receive" for N bytes until that many bytes are available? So no other signals than the one it is waiting on will wake the fiber at that point, correct? That's actually the desirable behaviour I think.

Yes, correct

After rawYield() continues, the event that caused this can be indirectly determined by asking the TCP connection if data is available, or by asking the Signal if the emit count was increased.

Alright, that makes sense. I implemented this model with a simple queue of outgoing packets. The main loop basically checks for incoming data, and consumes it all if any is available (it'll block waiting for a full packet to come in, etc). After that if there is anything pending in the send queue it will flush that all out (again, presumably blocking if the socket send buffer fills) and then do a rawYield. Basically the same model as the broadcast example, except I use one signal per client which fires when anything is added to that client's queue, as not all cross-client messages are broadcasts.

Seems to work properly, so modulo figuring out a policy for maximum send queue size, etc. I'm happy :)

I consider this just a temporary compromise to make this kind of bidirectional braodcasting work at all, with the danger that it relies on the way events are handled internally, which might (although probably not) change in the future or between different back ends.

Right, I'll put a big warning in my code that it might break in the future :) Presumably if it does break, the broadcast example will be updated with the new "best known method"?

One thing I thought about was writing a messaging API, compatible to std.concurrency, based on the fiber aware Signal/Mutex classes. That would cover such use cases in a nice and safe way and would also allow for painless migration if std.concurrency should ever support such fiber-aware thread primitives.

Am 06.01.2013 05:11, schrieb punkUser:

Just updated to the latest released version (0.7.10) and it seems like listen sockets aren't working
for me now. The function appears to succeed and everything, but there doesn't appear to be a socket
listening... any attempts to connect to it from another client just immediately fail.

I'm still using the libevent implementation. Any ideas?

That's unexpected. Do you get a "connection refused" error or something else?

Can you try to setLogLevel(LogLevel.Trace) and put the log on pastebin or similar? I'll take a look.

Hmm... the plot thickens: the firewall seems to see that vibe is hosting a listen socket (asks if it should be allowed), but still nothing is able to connect to it.

Even this relatively simple code doesn't work...

import vibe.vibe;
import std.stdio;

int main(string[] argv)
{
setLogFile("vibe_log.txt", LogLevel.Trace);

listenTcp(80, (conn) {

writeln(conn.peerAddress());

} );

runEventLoop();
return 0;
}

Chrome will say "couldn't connect", nothing printed in console or log, etc.

I realize I'm using vibe in a sort of weird way, but I'd like to control the entry points and link it just as a library rather than using the surrounding build infrastructure. It seemed to be working fine before, but not anymore :(

So to be clear what I'm doing is...

1) using provided visual D project
2) adding "vibe.d" and a few missing files in templ to it
3) removing stream/stream from it to eliminate warning
4) removing VibeWin32Driver version from compile options
5) linking resulting library in with my code (for example, the above)

Is this supposed to work or am I bypassing too much of the infastructure? Is there a preferred way for me to accomplish what I'm trying to do? Am I just missing some sort of initialization function or similar maybe?

Aha I think I found the issue... I'm calling the default "address-less" version of listenTcp then connecting to localhost. Before in vibe this would forward to "listenTcp(port, connection_callback, "0.0.0.0");", but as of the latest version it uses "::" as the default address instead. For some reason this is disrupting my ability to connect via IPv4.

Adding "0.0.0.0" as an explicit address to my listenTcp calls seems to have resolved the issue. I'm not sure if I fully understand the new logic in the address-less listenTcp to be honest... I'm guess the issue is that multiple listeners are created but the TcpListener object that was added doesn't support that so the idea is to return null instead? Except that return null only happens if the first listenTcp succeeds, and if that is the case it never calls the second one now. Perhaps a bug?