beepcore-c-users — Discussion list for developers using beepcore-c library

Re: [Beepcore-c-users] Another Beepcore-c Problem

[David C N. <dc...@ad...>]

On Tue, 23 Mar 2004, William J. Mills wrote:
> Hmmm.  What's the action when it throws the error?  Sending a MSG or
> an ANS/RPY/NUL?

It is in the middle of a lot of action, so it is pretty hard to tell
exactly what is happening when it occurs.  I'll try to pin that down
tomorrow.  I find it odd that it generally happens after several hundred
medium-sized messages have passed through.  If I send tiny (one-frame) 
messages, I managed to send >5000 without incident before finally giving 
up on the test.  So it probably is a frame-related problem.

Meanwhile, I may have solved my memory leak, but this did nothing to solve 
the problem.

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] Another Beepcore-c Problem

[William J. M. <wm...@es...>]

Hmmm.  What's the action when it throws the error?  Sending a MSG or
an ANS/RPY/NUL?

-bill


On Tue, Mar 23, 2004 at 12:53:24PM -0500, David C Niemi wrote:
> 
> I am getting the following message after sending a few hundred messages:
> 
> Unexpected error(7) Queued new message before previous answered
> 
> It comes out of CBEEP.c, but its meaning is a bit obscure to me.  I was 
> planning to more aggressively track it down once I've dealt with the 
> memory leaks.  Is anyone else familiar with what would cause it?
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] Another Beepcore-c Problem

[David C N. <dc...@ad...>]

I am getting the following message after sending a few hundred messages:

Unexpected error(7) Queued new message before previous answered

It comes out of CBEEP.c, but its meaning is a bit obscure to me.  I was 
planning to more aggressively track it down once I've dealt with the 
memory leaks.  Is anyone else familiar with what would cause it?

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] beepcore-c memory purity?

[David C N. <dc...@ad...>]

On Mon, 22 Mar 2004, William J. Mills wrote:
> Well, long ago, we used to run purify on it.  So the initial checkin
> was pretty clean.

How long ago was that, before or after the 0.2 release?

> One of the things that does happen is that there's A couple of thinsg
> that maintain their own free lists of unusued pre- allocated objects.  
> It's possible that's what you are seeing.
> 
> Does the memory usage peak?

It goes pretty high, 300+ MB total size, with RSS climbing to 100+ MB,
over the course of a couple hundred large messages.  So we're not talking
some little tiny buffers here, there's at least something happening
per-message, and quite likely per-frame.  Nothing statically allocated
could account for this kind of growth or total size.  OTOH, it is not
time-based; memory usage does not increase while the system is running
unless messages pass through it.

I have seem memory use sometimes drop a little bit now and then, only to 
rise again beyond its previous peaks as more messages are handled.

I think I have found a leak in my application profile, which could come to 
9K per message that applies to some types of messages, but that is a drop 
in the bucket compared to what I'm seeing.

---

To verify, for sending a chunk my understanding is that you use
bpc_buffer_allocate() to allocate a send buffer and populate it with your
data, and bpc_send ultimately destroys this buffer automatically once it
has been sent.

On the receive side, you get a frame in pro_frame_available which you free
by calling bpc_frame_destroy() when you are done with it.

There are other areas where I am not entirely confident about how memory 
is deallocated, but they are per-profile, per-channel, per-session, etc. 
and are thus not nearly as significant as these are all permanent 
allocations in the current application.

----

One other thing I noticed: it looks like the file of the profile's .cfg 
file is left open indefinitely.  I'd think it ought to be closed as soon 
as it's read.

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] beepcore-c memory purity?

[William J. M. <wm...@es...>]

Well, long ago, we used to run purify on it.  So the initial checkin
was pretty clean.  One of the things that does happen is that there's
A couple of thinsg that maintain their own free lists of unusued pre-
allocated objects.  It's possible that's what you are seeing.

Does the memory usage peak?

-bill


On Mon, Mar 22, 2004 at 05:34:13PM -0500, David C Niemi wrote:
> 
> I was wondering how well-tested memory allocation/deallocation is in 
> beepcore-c.  I find that pushing a few hundred messages (totaling a 
> few hundred MB) through a frame-oriented BEEP application, memory usage 
> creeps up rather alarmingly.  I'm not quite sure yet if the memory usage 
> is per-frame or per-message just yet, but it increases a lot more on a 
> large message than a small one.
> 
> It is of course possible that it is in my application, but I don't see any 
> OBVIOUS leaks there.  If anyone can vouch for beepcore-c having been 
> tested for memory leaks, that would help narrow my search a great deal.  I 
> am pretty confident bpc_frame_destroy() is reliably called on each frame, 
> for example.
> 
> I'm getting ready to release this application as open source in the fairly 
> near future, but I definitely need to track this one down first.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] beepcore-c memory purity?

[David C N. <dc...@ad...>]

I was wondering how well-tested memory allocation/deallocation is in 
beepcore-c.  I find that pushing a few hundred messages (totaling a 
few hundred MB) through a frame-oriented BEEP application, memory usage 
creeps up rather alarmingly.  I'm not quite sure yet if the memory usage 
is per-frame or per-message just yet, but it increases a lot more on a 
large message than a small one.

It is of course possible that it is in my application, but I don't see any 
OBVIOUS leaks there.  If anyone can vouch for beepcore-c having been 
tested for memory leaks, that would help narrow my search a great deal.  I 
am pretty confident bpc_frame_destroy() is reliably called on each frame, 
for example.

I'm getting ready to release this application as open source in the fairly 
near future, but I definitely need to track this one down first.

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] simultaneous close

[William J. M. <wm...@es...>]

Memory tells me we recognized that deadlock, and I thought we resolved
it.

As I remember the right thing is for one end to refuse the close and 
the other accepts it.  We did something arbitrary like initiator
should go ahead and close.  I guess that's not working.

The core dump is coming from the socket close event I think.  So it's
really 2 bugs.

Went and looked at the code.  Fix will be non-trivial.  Problem is that 
the way the code is I have it blocking n a wait loop.  Unfortunately I think
this is blocking the thread that needs to process the close from the other 
end.  There is no quick fix I think.  Major fault.  The wait is in 
waitfor_chan_stat_quiescent() and that is called from 
blw_close_request_non0().

I am not sure if we can put something in the waitfor function to 
process further events in chan 0 because I am not sure what the semaphore 
states are.  Theoretically the waitfor functions allow the right things to 
happen in other threads.  Might be able to solve this by dispatching
the events differently.  Not sure.

-bill


On Fri, Feb 13, 2004 at 01:32:23PM -0800, Lei Zhang wrote:
> Yep.  Looks like both sides wait for the channel status to be QUIESCENT, 
> but both sides are in the HALFCLOSE state.
> 
> William J. Mills wrote:
> 
> >Hmmmm...  well that's a bad bug.
> >
> >Simultaneous from both ends in same channel?
> >
> >-bill
> >
> >
> >On Fri, Feb 13, 2004 at 11:40:31AM -0800, Lei Zhang wrote:
> >
> >>Knowing that beepcore-c is dead, still it's worthwhile reporting this:
> >>
> >>beepcore-c is not able to handle simultaneous channel close.  I see the 
> >>following call sequences:
> >>
> >>  listener                   initiator
> >> 
> >>  close_indication local       close_indication local
> >>  close_indication remote      close_indication remote
> >>
> >>Neither side gets to the close_confirmation stage.  After waiting a 
> >>while, kill one peer, the other peer core dumps saying 'assertion 
> >>"wrap->iostate != 0" failed' in bp_notify.c.
> >>
> >>well, well...
> >>
> 
> 

Re: [Beepcore-c-users] simultaneous close

[Lei Z. <lz...@ju...>]

Yep.  Looks like both sides wait for the channel status to be QUIESCENT, 
but both sides are in the HALFCLOSE state.

William J. Mills wrote:

>Hmmmm...  well that's a bad bug.
>
>Simultaneous from both ends in same channel?
>
>-bill
>
>
>On Fri, Feb 13, 2004 at 11:40:31AM -0800, Lei Zhang wrote:
>
>>Knowing that beepcore-c is dead, still it's worthwhile reporting this:
>>
>>beepcore-c is not able to handle simultaneous channel close.  I see the 
>>following call sequences:
>>
>>  listener                   initiator
>> 
>>  close_indication local       close_indication local
>>  close_indication remote      close_indication remote
>>
>>Neither side gets to the close_confirmation stage.  After waiting a 
>>while, kill one peer, the other peer core dumps saying 'assertion 
>>"wrap->iostate != 0" failed' in bp_notify.c.
>>
>>well, well...
>>

Re: [Beepcore-c-users] simultaneous close

[William J. M. <wm...@es...>]

Hmmmm...  well that's a bad bug.

Simultaneous from both ends in same channel?

-bill


On Fri, Feb 13, 2004 at 11:40:31AM -0800, Lei Zhang wrote:
> Knowing that beepcore-c is dead, still it's worthwhile reporting this:
> 
> beepcore-c is not able to handle simultaneous channel close.  I see the 
> following call sequences:
> 
>   listener                   initiator
>  
>   close_indication local       close_indication local
>   close_indication remote      close_indication remote
> 
> Neither side gets to the close_confirmation stage.  After waiting a 
> while, kill one peer, the other peer core dumps saying 'assertion 
> "wrap->iostate != 0" failed' in bp_notify.c.
> 
> well, well...
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] simultaneous close

[Lei Z. <lz...@ju...>]

Knowing that beepcore-c is dead, still it's worthwhile reporting this:

beepcore-c is not able to handle simultaneous channel close.  I see the 
following call sequences:

  listener                   initiator
 
  close_indication local       close_indication local
  close_indication remote      close_indication remote

Neither side gets to the close_confirmation stage.  After waiting a 
while, kill one peer, the other peer core dumps saying 'assertion 
"wrap->iostate != 0" failed' in bp_notify.c.

well, well...

Re: [Beepcore-c-users] State of the BEEP

[Darren N. <dn...@sa...>]

William J. Mills wrote:
 > I can't see how the excess fragmentation has it's roots
 > in the wrapper.
 > All of the fragmentation is handled in core and
 > trasport/framing.  What
 > am I missing?

Nothing.

"The core portion would be usable [...] when the fragmentation bug gets 
fixed."

Yes, if there's a bug in fragmentation, it would be in the core. The 
"apparent" part was there only because I haven't personally seen the bug 
happen or figured out why or under what circumstances, and I did do some 
rather extensive testing while I was writing it, so I'm leaving open the 
possibility it was an operator error or something introduced later, in 
addition to some bug I left in there, is all.

-- 
Darren New, San Diego CA USA (PST)
   I am in geocentric orbit, supported by
   a quantum photon exchange drive....

Re: [Beepcore-c-users] State of the BEEP

[William J. M. <wm...@es...>]

I can't see how the excess fragmentation has it's roots in the wrapper.
All of the fragmentation is handled in core and trasport/framing.  What
am I missing?

-bill

> 
> I'm hoping that perhaps the core portion of it, doing the parsing and 
> channel handling and such is still usable, especially when the apparent 
> "excess fragmentation bug" gets fixed. Hopefully that would be a good 
> starting point for someone trying to redo a wrapper.
> 

Re: [Beepcore-c-users] State of the BEEP

[William J. M. <wm...@es...>]

Unicode in the payload?  That should work just fine.  
Payload can be arbitrary binary for that matter.

-bill

> 
> 
> there are a lot of stuff not complete with beepcore-c,
> what a bout unicode support? i managed to get
> beepcore-c compiled with visual studio but it almost
> need complete rewritting to merge it with existing
> unicode-aware application.
> 
> since you mentioned xml? do you use utf-8?
>   
> 
> _________________________________________________________

Re: [Beepcore-c-users] State of the BEEP

[David C N. <dc...@ad...>]

I don't think I'd say beepcore-c is PERMANENTLY dead.  Maybe just
sleeping.  It does do a lot of things well and has a promising structure
for real applications down the road, if it manages to get more attention
to performance and threading issues.  It needs more resources more than it
needs to be thrown out -- it seems obvious to me that a general-purpose
and unencumbered C implementation is critical to BEEP's ultimate success.  
I have considered looking at RoadRunner but was a bit in doubt as to its
current status and advantages/disadvantages relative to beepcore-c; and I
am already up and running on beepcore-c.

I have been using it in a real application, and have managed to work 
around a number of small problems; I am interested in helping to improve 
it down the road (though I don't have CVS access and am really focused on 
just a few parts of the source tree).

I think another key lack is in the area of documentation and examples.  
They both exist, but fall far short of what is needed to write a real
application using it without a great deal of help from the likes of Mssrs.  
Mills and New.

FWIW there has been a fair amount of discussion at times on this mailing
list at the times when I was actively working on using beepcore-c in my
application ;^)  But that probably doesn't constitute critical mass.

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] State of the BEEP

[Darren N. <dn...@sa...>]

William J. Mills wrote:
> I think the current implementation is far to grandiose in the way
> that we designed how the components work together.  We were trying 
> to do too much and make its the whiz bang fully extensible plug
> in whatever you wnat thing.

I'm hoping that perhaps the core portion of it, doing the parsing and 
channel handling and such is still usable, especially when the apparent 
"excess fragmentation bug" gets fixed. Hopefully that would be a good 
starting point for someone trying to redo a wrapper.

I've been considering doing an implementation in C#, but I just haven't 
had any time to devote to it. Of course, the performance would be 
somewhat lower, but you'd have the advantages of having a mechanism for 
handling threading, asynchronous dispatch, dynamically loaded modules, 
OO interfaces, built-in cryptography support, and so on. It would 
probably be a whole lot easier. Unfortunately, right now I'm spending my 
copious (<ahem>) free time on another project, but if someone was 
actually interested, I'd be glad to try to help.

-- 
Darren New, San Diego CA USA (PST)
   I am in geocentric orbit, supported by
   a quantum photon exchange drive....

Re: [Beepcore-c-users] State of the BEEP

[William J. M. <wm...@es...>]

Good intentions aside, I probably have to agree with Marshall.  I
have not made the time to address the bugs in the current implementation
much less do some of the mods I have thought about.

I have been rather hoping that we'd get some more folks jumping in
and writing code, which happened for a bit, but did not continue.

I think the current implementation is far to grandiose in the way
that we designed how the components work together.  We were trying 
to do too much and make its the whiz bang fully extensible plug
in whatever you wnat thing.

Perhaps the biggest problem in the current design is the threading,
which does not allow you to actually have a single threaded 
implementation.  Fixing this requires rewriting significantly parts
of the wrapper.

So, in the end I guess, it's pretty much in the closet and I don't
se myself putitting in the time it needs in the near future, and I'm 
the only one actively supporting it right now.  

-bill


On Tue, Jan 27, 2004 at 07:55:03AM -0800, Marshall Rose wrote:
> > Can anyone comment on the state of beep and beepcore-c?
>     
> hi. this is just my opinion. people should feel free to disagree...
>     
>     
> > There seems to be no real activity in the past year (no news, no
> > announcements, only 6 source code files modified during the entire
> > year).  10 of the 13 bugs are assigned to 'nobody' and 9 of the 13
> > are over a year old.  The mailing lists are also fairly quiet.
>     
> i agree. all this tells me is that beepcore-c is dead. any signs of motion
> is merely rigor slowly setting in.
>     
> i tried to get the guys with a commercial c implementation of beep to
> loosen up their licensing a bit to make it accessible to a larger
> community, but wasn't successful in this.
>     
>     
> > So my question is are these signs of a mature, bug-free, robust
> > software project, or one that's been mostly abandoned?  Are folks
> > using beep and beepcore-c?  How well used and widely deployed are
> > these technologies?  How large is the user and developer communities?
> > How active are they? Is beep a going concern?
> 
> in order:
>     
> abandoned.
>     
> not me, i use the tcl and java ipmlementations, am learning the cool
> python implementation, and have looked at a few others, e.g., the perl
> implementation and liblogging (the minimal beep stack written in c).
>     
> i use the tcl version in some internal projects.
>     
> i know a couple of companies that use the java version in commercial products.
> 
> go to http://beepcore.org/
>     
> tcl is bug-fixes only; java is fixes + minor enhancements; python just
> put out a major functional release. perl and liblogging appear stable.
>     
> based on the email i get on the topic, yes.
>     
> /mtr
> 
> 

Re: [Beepcore-c-users] State of the BEEP

[Marshall R. <mr...@db...>]

> Can anyone comment on the state of beep and beepcore-c?
    
hi. this is just my opinion. people should feel free to disagree...
    
    
> There seems to be no real activity in the past year (no news, no
> announcements, only 6 source code files modified during the entire
> year).  10 of the 13 bugs are assigned to 'nobody' and 9 of the 13
> are over a year old.  The mailing lists are also fairly quiet.
    
i agree. all this tells me is that beepcore-c is dead. any signs of motion
is merely rigor slowly setting in.
    
i tried to get the guys with a commercial c implementation of beep to
loosen up their licensing a bit to make it accessible to a larger
community, but wasn't successful in this.
    
    
> So my question is are these signs of a mature, bug-free, robust
> software project, or one that's been mostly abandoned?  Are folks
> using beep and beepcore-c?  How well used and widely deployed are
> these technologies?  How large is the user and developer communities?
> How active are they? Is beep a going concern?

in order:
    
abandoned.
    
not me, i use the tcl and java ipmlementations, am learning the cool
python implementation, and have looked at a few others, e.g., the perl
implementation and liblogging (the minimal beep stack written in c).
    
i use the tcl version in some internal projects.
    
i know a couple of companies that use the java version in commercial products.

go to http://beepcore.org/
    
tcl is bug-fixes only; java is fixes + minor enhancements; python just
put out a major functional release. perl and liblogging appear stable.
    
based on the email i get on the topic, yes.
    
/mtr

RE: [Beepcore-c-users] State of the BEEP

[<zh...@ya...>]

 --- Andy Dent <de...@oo...> 的正文：> > So my
question is are these signs of a mature,
> bug-free, 
> > robust software project, or one that's been mostly
> abandoned? 
> >  Are folks using beep and beepcore-c?  How well
> used and 
> > widely deployed are these technologies?
> 
> I think BEEP is well-defined and I used a slight
> variation (pure XML
> wrappers) for the IBVA brainwave protocols
> transmitting from c++ servers
> on PocketPC, Windows and OSX to a variety of clients
> including Python,
> Flash and RealBasic.
> 
> I didn't use beepcore-c because I perceived it as
> having deep bugs (a
> year ago) in subtle timing issues and I would have
> had to hack it anyway
> to go pure XML (something driven by an early
> architectural decision to
> talk to Flash).
> 
> Difficulties with the "out of the box" experience
> trying to compile
> beepcre-c at that time with Visual Studio (both for
> Windows and
> PocketPC) also discouraged me.
> 
> I have probably spent enough time debugging my own
> stack that I would
> have been equally well-off polishing beepcore-c.
> 
> I didn't use RoadRunner because of licensing issues
> and perceived
> difficulty in getting the various packages working
> on PocketPC.
> 
> 
> 
>
-------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and
> Integration
> See the breadth of Eclipse activity. February 3-5 in
> Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
>
https://lists.sourceforge.net/lists/listinfo/beepcore-c-users


there are a lot of stuff not complete with beepcore-c,
what a bout unicode support? i managed to get
beepcore-c compiled with visual studio but it almost
need complete rewritting to merge it with existing
unicode-aware application.

since you mentioned xml? do you use utf-8?
  

_________________________________________________________
Do You Yahoo!? 
繁华世界里，让我看清你
http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.surveys.yahoo.com/cn_user_profile_study_dec2003

RE: [Beepcore-c-users] State of the BEEP

[Andy D. <de...@oo...>]

> So my question is are these signs of a mature, bug-free, 
> robust software project, or one that's been mostly abandoned? 
>  Are folks using beep and beepcore-c?  How well used and 
> widely deployed are these technologies?

I think BEEP is well-defined and I used a slight variation (pure XML
wrappers) for the IBVA brainwave protocols transmitting from c++ servers
on PocketPC, Windows and OSX to a variety of clients including Python,
Flash and RealBasic.

I didn't use beepcore-c because I perceived it as having deep bugs (a
year ago) in subtle timing issues and I would have had to hack it anyway
to go pure XML (something driven by an early architectural decision to
talk to Flash).

Difficulties with the "out of the box" experience trying to compile
beepcre-c at that time with Visual Studio (both for Windows and
PocketPC) also discouraged me.

I have probably spent enough time debugging my own stack that I would
have been equally well-off polishing beepcore-c.

I didn't use RoadRunner because of licensing issues and perceived
difficulty in getting the various packages working on PocketPC.

[Beepcore-c-users] State of the BEEP

[Phil S. <ph...@ju...>]

Can anyone comment on the state of beep and beepcore-c?

There seems to be no real activity in the past year (no news, no
announcements, only 6 source code files modified during the entire
year).  10 of the 13 bugs are assigned to 'nobody' and 9 of the 13
are over a year old.  The mailing lists are also fairly quiet.

So my question is are these signs of a mature, bug-free, robust
software project, or one that's been mostly abandoned?  Are folks
using beep and beepcore-c?  How well used and widely deployed are
these technologies?  How large is the user and developer communities?
How active are they? Is beep a going concern?

Thanks,
 Phil

[Beepcore-c-users] [noreply@sourceforge.net: [ beepcore-c-Bugs-877390 ] file missing for win32 build]

[William J. M. <wm...@es...>]

Can someone remind me please what the standard source for
getopt() in windows is?

I can't remember.

-bill


----- Forwarded message from "SourceForge.net" <no...@so...> -----

To: no...@so...
From: "SourceForge.net" <no...@so...>
Subject: [ beepcore-c-Bugs-877390 ] file missing for win32 build
Date: Thu, 15 Jan 2004 00:04:06 -0800

Bugs item #877390, was opened at 2004-01-15 08:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=406498&aid=877390&group_id=32788

Category: build/installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lionel Zhou (asimo)
Assigned to: William Mills (sweetums)
Summary: file missing for win32 build

Initial Comment:
the getopt.h and getopt.c source file needed by beepd.c
are missing from the tarball and CVS.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=406498&aid=877390&group_id=32788

----- End forwarded message -----

[Beepcore-c-users] <close number='0'> while peer is sending a huge message

[Lei Z. <lz...@ju...>]

Hi,

I've been fighting with this for a long day with no avail: if my request 
to release the session is sent to the peer while the peer is sending us 
a huge message (fragmented into multiple frames), then the session gets 
stuck.  The remaining frames of the huge message do not get sent out and 
the peer cannot <ok> the close request.  Can anybody give me a hint as 
to where to go digging?

Help greatly appreciated,
Lei

[Beepcore-c-users] Profile "dataname" and config_get questions

[David C N. <dc...@ad...>]

I am trying to do some smarter use of BEEP's config file support in my 
application.  Is there some easy way for a profile to find out what 
"dataname" its configuration came from?  I would like to make use of this.

Without knowing the "dataname", how can one reliably know what to load in 
for various parameters?  config_get seems to require an exact path to 
where the parameter you want is.  So for example:

<beep ...>
  <profiles>
     ...
  </profiles>
  <myappname>
    <application>
       <dataname1>
          <criticalitem>foo1</criticalitem>
       </dataname1>
       <dataname2>
          <criticalitem>foo2</criticalitem>
       </dataname2>
    </application>
  </myappname>
</beep>

I'd like the profile to be able to figure out that its dataname is 
"dataname1", and to figure out that its criticalitem is "foo1", as opposed 
to "foo2".  do I need to use the config_search_* functions?  Or can I look 
for a disembodied <criticalitem> and expect that the tree is pruned to 
just the dataname that applies to this profile instance?

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] Mysterious socket error

[David C N. <dc...@ad...>]

I believe I've solved (or at least papered over) the problems I was seeing
by doing my own rigorous locking before I even start looking at a frame in
pfa().  Now only one thread can get anywhere useful in pfa() on a given
message at one time, and I am not misplacing messages, nor am I getting
dropped sessions, at least not in moderate testing.

Although it would seem this sort of per-message locking should not even be
needed, since I've worked around it, the main problem I have to complain
about now is the still unexplained frame fragmentation that beepcore-c is
doing to even small (<2K) messages.  I expect it hurts performance and
should be something I can avoid.  I may have time to pursue it myself in a
few months, but in the mean time everyone should be aware that it is
lurking.  For those people doing message-oriented stuff rather than
frame-oriented, I'd guess it is afflicting you as well, but it is
low-level enough you don't notice.

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] Mysterious socket error

[Lei Z. <lz...@ju...>]

I did not mean thread_per_channel, I meant "thread per channel" - one
worker thread for each channel a session contains.  It's probably 10 - 20
lines of wrapper code change.

BTW, there is memory leak/socket leak/thread leak in the beepcore-c
library (or should I say pilot error).  An example: the worker threads
probably should call pthread_detach() as the first thing...

Lei

On Sat, 10 Jan 2004, David C Niemi wrote:

> On Fri, 9 Jan 2004, Lei Zhang wrote:
> > I've noticed this too.  I changed the threading model to one thread per
> > channel a couple of months ago, that probably explains why I'm not
> > having the problem that's bothering David.
>
> As far as I can see, this is NOT what thread_per_channel does -- without
> it, there would be only one thread allocated total, as opposed to one per
> channel.  Although pfa() does seem to get called multiple times
> concurrently, evidently meaning there are multiple threads.