Re: [Libevent-users] evrpc_status structure.
On Mon, Jan 21, 2013 at 9:28 PM, fabien pichot wrote: > Hello, > > I'm currently working on a prototype of decentralized VPN, and I'm > using libevent for anything related to network. > > Recently, I decided to write RPC to communicate between my nodes. And > after a quick hovering on evrpc/evhttp, I decided to give it a shot. > > However, when I tried to check for errors in the callback of > EVRPC_MAKE_REQUEST, I realized that the struct evrpc_status is only > forward declared in event2/rpc.h. In consequence, there is no portable > and forward compatible way to access the error field nor to compare it > against any of it's error codes, as they are defined in > event2/rpc_struct.h. > > Am I doing things wrong ? > > I'll probably submit a patch in the near future to make a public API > to access theses fields, if no one tell me not to so. > A public API to access these fields would be the right thing. First, make sure that we didn't add them already in the 2.1 series -- but I'm pretty sure we haven't done so yet. best wishes, -- Nick *** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-usersin the body.
Re: [Libevent-users] evhttp client error handling
Azat Khuzhin wrote: Also on which operating system did you work? Ubuntu 10.04 LTS: Linux chives 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC 2011 x86_64 GNU/Linux But the operating system doesn't really matter. This is a general problem with evhttp, regardless of OS. Maybe this will be useful for you http://instantbadger.blogspot.ru/2010/06/eafnosupport-socket-connection-issue-on.html Sure, obviously you can sweep the problem under the carpet by only using IPv4. That's what I'm doing now: I have a horrible little hack that compares the hostname with "localhost" and replaces it with "127.0.0.1" in that case. But that does nothing to address the underlying problem that evhttp doesn't support IPv6. Although IPv6 is still in the minority, and adoption is slow, it's still something we ought to support. If evhttp is IPv4-only, it is not future-proof. On Sun, Jan 20, 2013 at 7:18 PM, Azat Khuzhin wrote: But "ai" can't be NULL in "bind_socket_ai()", see https://github.com/libevent/libevent/blob/0c2bacca43ffe452d4f5cdc4b57fd29a7795777d/http.c#L4088 Sure it can. It's explicitly called with NULL right here: https://github.com/libevent/libevent/blob/b452a4345088dcc7e7491bcff612f9f11dfb17da/http.c#L4084 address and port are going to be NULL, because they come from evcon->bind_address and evcon->bind_port: https://github.com/libevent/libevent/blob/b452a4345088dcc7e7491bcff612f9f11dfb17da/http.c#L2336 and evcon->bind_address and evcon->bind_port default to NULL, and are going to stay NULL, unless evhttp_connection_set_local_address() or evhttp_connection_set_local_port() are called. But these wouldn't normally be called in the client case. The example that I'm basing my code off of doesn't call them: http://archives.seul.org/libevent/users/Mar-2012/binGP2R6ys0C_.bin and it doesn't make sense for the client to call them anyway. In the client case, you want to use whichever local address will allow you to reach the remote address. So we are once again back to our chicken-and-egg problem, that you have to resolve the remote address (and know whether it is IPv4 or IPv6) before you can create the socket. It doesn't make sense any other way. --Patrick *** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-usersin the body.
