Ack, missed how the read was pulling the data off. Nice catch Nick...
> > static void OnRead(struct bufferevent *bev, void *user_data)
> > {
> > int buf_len = evbuffer_get_length(bufferevent_get_input(bev));
> > ConnectionContext *ctx = user_data;
> > uint8_t size_data[4],*data;
> >
On Tue, Feb 8, 2011 at 6:45 PM, Ivan Novick wrote:
> On Tue, Feb 8, 2011 at 11:08 AM, Nick Mathewson wrote:
>> On Mon, Feb 7, 2011 at 5:15 PM, Ivan Novick wrote:
>>> Hello,
>>>
>>> I am testing fault tolerance in my application that is written using
>>> libevent-1.4.6
>>
>> I'd seriously suggest
On Tue, Feb 8, 2011 at 11:08 AM, Nick Mathewson wrote:
> On Mon, Feb 7, 2011 at 5:15 PM, Ivan Novick wrote:
>> Hello,
>>
>> I am testing fault tolerance in my application that is written using
>> libevent-1.4.6
>
> I'd seriously suggest that you always use the latest stable release,
> or at the v
On Feb 8, 2011, at 8:08 PM, Nick Mathewson wrote:
>> Do you know how I can detect the disconnection caused by bringing down
>> the interface on the server ... while still using libevent?
>
> If there's a good way to do this, Libevent or no, I'd like to know about it
> too.
The best reliable wa
On Tue, Feb 8, 2011 at 2:16 PM, Wayne Shao wrote:
> Hi,
> I am using a filter to read packets from the peer. The packet format is
> typical header + payload, where total length is encoded in the header.
> In the filter callback, is it possible to only consume part of the source
> buffer?
> e.g, if
On Tue, Feb 08, 2011 at 02:08:39PM -0500, Nick Mathewson wrote:
> On Mon, Feb 7, 2011 at 5:15 PM, Ivan Novick wrote:
> > Do you know how I can detect the disconnection caused by bringing down
> > the interface on the server ... while still using libevent?
>
> If there's a good way to do this, Li
Hi,
I am using a filter to read packets from the peer. The packet format is
typical header + payload, where total length is encoded in the header.
In the filter callback, is it possible to only consume part of the source
buffer?
e.g, if my protocol packet size is 100 bytes but the source buffer ha
On Mon, Feb 7, 2011 at 5:15 PM, Ivan Novick wrote:
> Hello,
>
> I am testing fault tolerance in my application that is written using
> libevent-1.4.6
I'd seriously suggest that you always use the latest stable release,
or at the very least the most recent stable release in the 1.4.x
series. Ther
On Tue, Feb 8, 2011 at 7:48 AM, Jeroen Habraken wrote:
> Hi,
>
> On lines 1499 and 1500 in evutil.c from libevent-2.0.10-stable I've
> found the following:
>
> #define USE_INTERNAL_NTOP
> #define USE_INTERNAL_PTON
>
> which leads to the built-in inet_ntop and inet_pton never being used.
> Why are
On 2011-02-08 00:33, William Ahern wrote:
> getaddrinfo()/getnameinfo() are definitely more abstract than their
> predecessor interfaces, but they're not abstract enough. Rather than presume
> IPv4, they basically presume TCP.
What do you mean? I've been using them with UDP without any issues...
Hi,
On lines 1499 and 1500 in evutil.c from libevent-2.0.10-stable I've
found the following:
#define USE_INTERNAL_NTOP
#define USE_INTERNAL_PTON
which leads to the built-in inet_ntop and inet_pton never being used.
Why are these defined?
Regards,
Jeroen Habraken
I have try the patch, but seems no use ><
But I use
bev1 = bufferevent_socket_new()
bev2 = bufferevent_openssl_filter_new()
instead of
bev = bufferevent_openssl_socket_new()
The lock problem seems solved in multi-thread.
But I don't know what the key point between them.
Brian
2011/1
12 matches
Mail list logo
