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

Re: [Beepcore-c-users] Unnecessary Frame Fragmentation using beepcore-c?

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

Welll.......  setting the window size can certainly be done as a define.

Lemme see if I can remember if there is a tuning function.

-bill


On Thu, Sep 11, 2003 at 10:28:32AM -0400, David C Niemi wrote:
> 
> Darren's suggestion about sending too fast and your suggestion about the
> window size both sound promising.  The very first few frames were not
> fragmented, but before long it began to fragment as I described, and I was
> indeed feeding the frames in very rapidly.
> 
> So how does one adjust the window size, and what is a sensible amount to 
> set it to?  This is currently running over loopback, where MTU is 16K.
> 
> Meanwhile I've modified my application to reassemble the tiny fragments as
> needed, but I expect that avoiding the fragmentation in the first place
> will substantially improve performance.
> 
> DCN
> 
> On Wed, 10 Sep 2003, William J. Mills wrote:
> > This has to do with the frame size and window size.  The data payload
> > will be reduced by the amount of the frame headers, which is the 
> > missing info to make the payload sizes make more sense I think.
> > 
> > My suspicion is that the frame and window sizes are perhaps
> > similar....  try cranking up the window size and see what that does.
> > 
> > -bill
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Re: [Beepcore-c-users] Unnecessary Frame Fragmentation using beepcore-c?

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

Darren's suggestion about sending too fast and your suggestion about the
window size both sound promising.  The very first few frames were not
fragmented, but before long it began to fragment as I described, and I was
indeed feeding the frames in very rapidly.

So how does one adjust the window size, and what is a sensible amount to 
set it to?  This is currently running over loopback, where MTU is 16K.

Meanwhile I've modified my application to reassemble the tiny fragments as
needed, but I expect that avoiding the fragmentation in the first place
will substantially improve performance.

DCN

On Wed, 10 Sep 2003, William J. Mills wrote:
> This has to do with the frame size and window size.  The data payload
> will be reduced by the amount of the frame headers, which is the 
> missing info to make the payload sizes make more sense I think.
> 
> My suspicion is that the frame and window sizes are perhaps
> similar....  try cranking up the window size and see what that does.
> 
> -bill

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

Re: [Beepcore-c-users] Unnecessary Frame Fragmentation using beepcore-c?

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

David C Niemi wrote:
 > It seems almost as though the frame sizes are random, although it does
 > settle into a rhythm of 3568 + 528 byte frames about halfway through a 1
 > MB file.  The entire file does always make it intact, eventually.

It's been a long time since I worked on this, but I suspect that what's 
happening is you're buffering up frames faster than they can be sent, 
and every time the beepcore-c library gets a SEQ, it's sending as much 
as it can. That is, the caller is reading less than 4K at a time, 
sending a SEQ, and at that point you're sending the next chunk, however 
big fits.

Try watching the SEQ messages going back and forth and see if they match 
the packet sizes.

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

Re: [Beepcore-c-users] Unnecessary Frame Fragmentation using beepcore-c?

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

This has to do with the frame size and window size.  The data payload
will be reduced by the amount of the frame headers, which is the 
missing info to make the payload sizes make more sense I think.

My suspicion is that the frame and window sizes are perhaps
similar....  try cranking up the window size and see what that does.

-bill


On Wed, Sep 10, 2003 at 12:55:47PM -0400, David C Niemi wrote:
> 
> I have an application that sends potentially large files using beepcore-c.  
> It sometimes manages to send them in CHUNKSIZE (4K) frames, but other 
> times it sends 4K frames and when they get to the other side they are 
> badly fragmented.  This seems rather inefficient and at times downright 
> inconvenient; I'd like to be able to count on at least very small frames 
> making it intact.
> 
> I am using the latest CVS version.
> 
> Does anyone know where or why this fragmentation would be introduced, and 
> whether it might be remedied somehow?  Here is an example of what is 
> happening:
> 
> Sender:
> Calling send_chunk for 4096 bytes, final=0, msgno=5.
> Calling send_chunk for 4096 bytes, final=0, msgno=5.
> ...
> Calling send_chunk for 4096 bytes, final=0, msgno=5.
> Calling send_chunk for 3977 bytes, final=1, msgno=5.
> 
> Receiver:
> SEND frame_available: type=M number=5 answer=-1 more=* size=2788
> SEND frame_available: type=M number=5 answer=-1 more=* size=1136
> SEND frame_available: type=M number=5 answer=-1 more=* size=172
> SEND frame_available: type=M number=5 answer=-1 more=* size=2616
> SEND frame_available: type=M number=5 answer=-1 more=* size=1136
> SEND frame_available: type=M number=5 answer=-1 more=* size=344
> SEND frame_available: type=M number=5 answer=-1 more=* size=2444
> SEND frame_available: type=M number=5 answer=-1 more=* size=1136
> SEND frame_available: type=M number=5 answer=-1 more=* size=516
> ...
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=* size=3568
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=* size=3568
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=* size=3568
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=. size=3449
> 
> It seems almost as though the frame sizes are random, although it does 
> settle into a rhythm of 3568 + 528 byte frames about halfway through a 1 
> MB file.  The entire file does always make it intact, eventually.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] Unnecessary Frame Fragmentation using beepcore-c?

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

I have an application that sends potentially large files using beepcore-c.  
It sometimes manages to send them in CHUNKSIZE (4K) frames, but other 
times it sends 4K frames and when they get to the other side they are 
badly fragmented.  This seems rather inefficient and at times downright 
inconvenient; I'd like to be able to count on at least very small frames 
making it intact.

I am using the latest CVS version.

Does anyone know where or why this fragmentation would be introduced, and 
whether it might be remedied somehow?  Here is an example of what is 
happening:

Sender:
Calling send_chunk for 4096 bytes, final=0, msgno=5.
Calling send_chunk for 4096 bytes, final=0, msgno=5.
...
Calling send_chunk for 4096 bytes, final=0, msgno=5.
Calling send_chunk for 3977 bytes, final=1, msgno=5.

Receiver:
SEND frame_available: type=M number=5 answer=-1 more=* size=2788
SEND frame_available: type=M number=5 answer=-1 more=* size=1136
SEND frame_available: type=M number=5 answer=-1 more=* size=172
SEND frame_available: type=M number=5 answer=-1 more=* size=2616
SEND frame_available: type=M number=5 answer=-1 more=* size=1136
SEND frame_available: type=M number=5 answer=-1 more=* size=344
SEND frame_available: type=M number=5 answer=-1 more=* size=2444
SEND frame_available: type=M number=5 answer=-1 more=* size=1136
SEND frame_available: type=M number=5 answer=-1 more=* size=516
...
SEND frame_available: type=M number=5 answer=-1 more=* size=528
SEND frame_available: type=M number=5 answer=-1 more=* size=3568
SEND frame_available: type=M number=5 answer=-1 more=* size=528
SEND frame_available: type=M number=5 answer=-1 more=* size=3568
SEND frame_available: type=M number=5 answer=-1 more=* size=528
SEND frame_available: type=M number=5 answer=-1 more=* size=3568
SEND frame_available: type=M number=5 answer=-1 more=* size=528
SEND frame_available: type=M number=5 answer=-1 more=. size=3449

It seems almost as though the frame sizes are random, although it does 
settle into a rhythm of 3568 + 528 byte frames about halfway through a 1 
MB file.  The entire file does always make it intact, eventually.

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

[Beepcore-c-users] beepng testfile hangs when using tls

[Srinivas <sri...@nc...>]

Hi,

I am trying to use tls in beepng file and its hanging while checking the
pl_status and pl_flags of the PROFILE_LOCAL_DATA (That's at YIELD() call)

can any one help me out

Thanka and regards,
Srinivas.

[Beepcore-c-users] Interest in Another c++ Stack?

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

BEEPX is a sort of BEEP descendant, after the first frame it becomes pure
XML even for the framing. That's because it was designed for use with Flash.

However, the parsing bit which assumes XML framing is well-isolated and
could be easily modified.

The stack uses only plain C++ that runs on PocketPC (Embedded VC3), Windows
and OS/X.

I'm considering if it would help me in some final debugging to have it open
sourced or not because I'll have to convince my client that it wouldn't be
a time-wasting distraction.

The only 3rd party libraries that BEEPX uses are some of the utilities from
my OOFILE suite and expatpp - my OO layer on top of expat. Both are
released under the Mozilla license, as would be BEEPX.

How much interest is there out there?

It runs fairly well and I have Python tests (not really an implementation
of the stack as they don't retain messages) that help exercise the echo
profile etc. There are also quite a few unit tests (the entire suite is 120
tests at present but many of those are app-specific) using cppunit on VC
and CodeWarrior for Mac, no PocketPC tests at present.

Unlike most of the projects I've seen, it is based around commercial
compilers, being developed on CodeWarrior Pro 8.3 for Mac (also builds with
ProjectBuilder), Visual C++ and Embedded VC. It doesn't require a deep
understanding of Unix development idioms to build.

Remember, I'm making no promises but if I have a few people willing to be
enthusiastic about using and testing this stuff then I will hopefully be
able to convince my client he's better off with it open sourced.

I'll have to contribute my time to packaging it and stripping some
proprietary stuff from the documentation, so I'm not making this offer
lightly - apart from being overloaded with work I'm still coping with the
effects of us moving to a new house and the "fixup period".

As an example, the complete Echo Profile is included below.

Expatpp <http://www.oofile.com.au/xml/expatpp.html> makes it very easy to
write call-back driven C++ parsers for expat and particularly to invoke
"subroutine" parsers so you can write very small sub-parsers that are
invoked when appropriate.

#include "BEEPXEchoProfile.h"
#include "BEEPXErrorReporter.h"

#include <assert.h>

#ifdef OOF_MEM_DEBUG_LAST_INCLUDE
	#include OOF_MEM_DEBUG_LAST_INCLUDE
#endif

using namespace BEEPX;


// -------------------------------------------------------
//    E c h o S e s s i o n F a c t o r y
// -------------------------------------------------------

EchoProfile EchoSessionFactory::sEchoProfile;


/**
	\return Session owned by caller.
*/
Session*
EchoSessionFactory::makeSession(Transport* adoptedTransport, ErrorReporter*
inReporter, SessionOwner* inOwner)
{
	Session* orphanedSession = new Session(adoptedTransport,
inReporter, inOwner);
	orphanedSession->registerProfile(&sEchoProfile);
	return orphanedSession;
}


// -------------------------------------------------------
//    E c h o P r o f i l e
// -------------------------------------------------------
oofString EchoProfile::sEchoURI = "http://ibva.com/BEEPX/Echo";

bool
EchoProfile::matchesURI(const char* matchingURI) const
{
	assert(matchingURI);
	return (sEchoURI==matchingURI);
}


const oofString&
EchoProfile::uri() const
{
	return sEchoURI;
}


ChannelParser*
EchoProfile::makeParser(const char* matchingURI)
{
	if (!matchingURI || matchesURI(matchingURI))
		return new EchoParser;
	else
		return 0;
}


// -------------------------------------------------------
//    E c h o P a r s e r
// -------------------------------------------------------

/**
	Just send back the raw payload as it was for any incoming MSG.
	If we responded regardless of type, would have an echo storm!
*/
void
EchoParser::parseFrame(Frame* inFrame)
{
	assert(inFrame);
	assert(mErrorReporter);
	mCurrentFrame = inFrame;
	mErrorReporter->resetError();
	assert (inFrame->type()==Frame::eMSG);
	const oofString raw = RawPayload(inFrame);
	Reply(raw);
	StCriticalSection protectMember(this);
	mLastFrameParsed = *inFrame;  // hang onto for unit tests
}


void
EchoParser::parseReplyFrame(Frame* inMessageSent, Frame* inReply)
{
	StCriticalSection protectMember(this);
	mLastReplyFrameParsed = *inReply;  // hang onto for unit tests
}



========================
The above Echo parser intercepts the entire frame. Normally you would write
something lower level which responded to the XML, like this.

void TriggerRequestParser::startElement(const XML_Char *name, const
XML_Char **atts)
{
	if (IgnoringContent())
		return;

	if(strcmp(name,"TriggerRequest")==0) {
		mState = eBuildingRequest;
		ParseRequestAtts(atts);
	}
	else if(strcmp(name,"Peak")==0) {
		StartPeak(atts);
	}
	else if(strcmp(name,"Average")==0) {
		StartAverage(atts);
	}
	else if(strcmp(name,"Sum")==0) {
		StartSum(atts);
	}
	else if(strcmp(name,"CompareRange")==0) {
		StartCompareRange(atts);
	}
	else if(strcmp(name,"Frequency")==0) {
		StartFrequency(atts);
	}
	else {
		handleUnknown(name, atts);
	}
}



-- 

Andy Dent BSc  MACS  AACM   http://www.oofile.com.au/
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability

[Beepcore-c-users] BEEP Example in C/C++

[Qian, L. <Li...@fo...>]

Hi MarShall,


Can you help me to find a completed BEEP application (using C/C++ on the
WIN32) example? Thanks!


Best Regards,


Liqun Qian

[Beepcore-c-users] Crash when re-using message number

[Sam C. <sa...@co...>]

Simple patch is attached to stop the core library crashing when a
message number is reused in violation of the BEEP protocol requirements.
-- 
Sam "Eddie" Couter  |  mailto:sa...@co...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@te...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[Beepcore-c-users] Re: Starting with beepcore-c

[Chris H. <cp...@zu...>]

   Date: Fri, 4 Apr 2003 00:51:44 +0200
   From: Sean de Kock <de...@wo...>

   I found them in threaded_os/examples/unix/.libs. I hav ealready
   tried to copy them to the examples directory - that did not work. I
   also tried to copy them straight into /usr/lib but that didn't work
   either. I saw in the beepd script they relink a bunch of stuff but
   never any of the profiles, should they have been linked as well - I
   am not familiar with the way c loads libuaries at runtime? I see in
   the beepng script the profiles are linked.

If you want to run the examples without installing beepcore-c into
your system, the simplest way to do this is

    cd threaded_os/examples/unix
    libtool --mode=execute ./beepd ...other args...

and likewise for beepng.

Even if you install beepcore-c, you'll still need to do this to get
the examples running, unless you decide to install the examples as
well.

This whole process is documented in the libtool manual.  For example,
see section 4.3 of the manual for the definition of execute mode.

Chris

Re: [Beepcore-c-users] Re: Starting with beepcore-c

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

Might be you need to set LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. so it
will pick up the .so from the current directory.

It links against the .so and then should load it at runtime
if it can find it.

-bill


On Fri, Apr 04, 2003 at 12:51:44AM +0200, Sean de Kock wrote:
> On Fri 04 Apr 03 00:45, you wrote:
> > I haven't played around too much with it since the autoconf
> > stuff was completed and the changes to start using libtool.
> >
> > If the profile .so files are not in the examples directory after
> > the build, go find them and copy into the example directory.
> > This should allow the profile to be loaded.
> >
> > -bill
> 
> I found them in threaded_os/examples/unix/.libs. I hav ealready tried to copy 
> them to the examples directory - that did not work. I also tried to copy them 
> straight into /usr/lib but that didn't work either. I saw in the beepd script 
> they relink a bunch of stuff but never any of the profiles, should they have 
> been linked as well - I am not familiar with the way c loads libuaries at 
> runtime? I see in the beepng script the profiles are linked.
> 
> Sean

Re: [Beepcore-c-users] Re: Starting with beepcore-c

[Sean de K. <de...@wo...>]

On Fri 04 Apr 03 00:45, you wrote:
> I haven't played around too much with it since the autoconf
> stuff was completed and the changes to start using libtool.
>
> If the profile .so files are not in the examples directory after
> the build, go find them and copy into the example directory.
> This should allow the profile to be loaded.
>
> -bill

I found them in threaded_os/examples/unix/.libs. I hav ealready tried to copy 
them to the examples directory - that did not work. I also tried to copy them 
straight into /usr/lib but that didn't work either. I saw in the beepd script 
they relink a bunch of stuff but never any of the profiles, should they have 
been linked as well - I am not familiar with the way c loads libuaries at 
runtime? I see in the beepng script the profiles are linked.

Sean

Re: [Beepcore-c-users] Re: Starting with beepcore-c

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

I haven't played around too much with it since the autoconf
stuff was completed and the changes to start using libtool.

If the profile .so files are not in the examples directory after
the build, go find them and copy into the example directory.  
This should allow the profile to be loaded.

-bill


On Fri, Apr 04, 2003 at 12:37:54AM +0200, Sean de Kock wrote:
> Hi,
> 
> > The profiles are built and the .so is somewhere findable and loadable?
> 
> I did a make in the beepcore-c directory so I am presuming that all the
> profiles are built. Where is somewhere findable? When I do a make install
> does it not put them in a findable place??
> 
> Sean
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] Re: Starting with beepcore-c

[Sean de K. <de...@wo...>]

Hi,

> The profiles are built and the .so is somewhere findable and loadable?

I did a make in the beepcore-c directory so I am presuming that all the
profiles are built. Where is somewhere findable? When I do a make install
does it not put them in a findable place??

Sean

Re: [Beepcore-c-users] Starting with beepcore-c

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

The profiles are built and the .so is somewhere findable and loadable?

-bill


On Wed, Apr 02, 2003 at 01:40:15PM +0200, De Kock SJ <136...@su...> wrote:
> Hello,
> 
> I have just started looking into beepcore-c. I have been using beepcore-java for the past 4 months so I am fairly familiar with BEEP. I tried to run the beepd program using the config file in examples by:
> 
> in exaples directory -
> ./unix/beepd -f beepd.cfg -p 10288
> 
> which gave this output:
> no profiles loaded, consult log file
> 
> What am I doing wrong or is there a problem with the config file?
> 
> I am currently running on two machines one with Redhat 7.2 and the other with RH 8.0. On the 7.2 machine the make runs without a problem but on the 8.0 there ends up being a whole bunch of sasl_... undefined errors fro various files. Is there a problem with the latter compiler or am I missing some libuaries?
> 
> Has any one done any work on xmlrpc-beep? I have implemented it for beepcore-java and am now thinking of doing the same for beepcore-c.
> 
> Regards,
> Sean
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] Starting with beepcore-c

[De K. SJ <136...@su...>]

Hello,

I have just started looking into beepcore-c. I have been using =
beepcore-java for the past 4 months so I am fairly familiar with BEEP. I =
tried to run the beepd program using the config file in examples by:

in exaples directory -
./unix/beepd -f beepd.cfg -p 10288

which gave this output:
no profiles loaded, consult log file

What am I doing wrong or is there a problem with the config file?

I am currently running on two machines one with Redhat 7.2 and the other =
with RH 8.0. On the 7.2 machine the make runs without a problem but on =
the 8.0 there ends up being a whole bunch of sasl_... undefined errors =
fro various files. Is there a problem with the latter compiler or am I =
missing some libuaries?

Has any one done any work on xmlrpc-beep? I have implemented it for =
beepcore-java and am now thinking of doing the same for beepcore-c.

Regards,
Sean

[Beepcore-c-users] File transfer

[WAYNE I. B. S. <WI...@bl...>]

Hi all.   Thanks for your previous assistance on my file transfer problem.  So 
far, I have my profile working with MSG/RPY.  Msg says "Start a new file" and 
RPY says "here's the file"  over and over until it's done.   The problem is that
 the frames are not always delivered up in the correct order.   Someones it is 
one or two, other times it is many.  Here's an example of the log file on the 
file receiving end:

02/27 11:01:55 blpmime  0.wrap <<< RPY 1 102 * 41213 77\r
02/27 11:01:55 blpmime  1.wrap read 82 octets
02/27 11:01:55 blpmime  0.wrap <<< 
MX6GUAho79sYAp2LCQeNQJ6CYKiGmOhAEP/eE1aUwAp4SXiIDJQwGIV76jV+NJDlmkEwrspwS2sX
02/27 11:01:55 blpmime  0.wrap <<< END\r
02/27 11:01:55 blpmime  1.wrap read 22 octets
02/27 11:01:55 blpmime  0.wrap <<< RPY 1 102 * 41290 77\r
02/27 11:01:55 blpmime  1.wrap read 82 octets
02/27 11:01:55 blpmime  0.wrap <<< 
PBE5Uew1HYJIGw+eQ7yu54rAfNhkfWQBq8tB+iaF1B8FSNLgmE5Kg0smrOj8+R8l0dQZSxdx60qd
02/27 11:01:55 blpmime  0.wrap <<< END\r

However, my profile traces this receipt thus: (this is almost an exact copy of 
the ECHO profile...)

FILE frame_available: type=R number=102 answer=-1 more=*, size=77
A3pRneLb7TdMjTYOH4gwpd9jak3Myk+wGTSUYzqVtjLbOaW6OnpHz4AgInjzGae2CD/iDTPMP0OR
FILE frame_available: type=R number=102 answer=-1 more=*, size=77
FILE frame_available: type=R number=102 answer=-1 more=*, size=77
PBE5Uew1HYJIGw+eQ7yu54rAfNhkfWQBq8tB+iaF1B8FSNLgmE5Kg0smrOj8+R8l0dQZSxdx60qd
MX6GUAho79sYAp2LCQeNQJ6CYKiGmOhAEP/eE1aUwAp4SXiIDJQwGIV76jV+NJDlmkEwrspwS2sX
FILE frame_available: type=R number=102 answer=-1 more=*, size=77

What's disturbing is the way those lines in the middle are interleaved.  Is this
 a thread synch. problem??

Thanks.
Wayne.

Re: [Beepcore-c-users] Beepcore-c and MIME

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

teh base64 bits are for handling binary data in the profile startup
piggyback data, and are not really exposed via the wrapper.

I don't think MIME is integrated in the c side like it is on 
the java side, though I could be wrong.

-bill


On Mon, Feb 24, 2003 at 01:16:06PM -0500, WAYNE IRONS, BLOOMBERG/ SKILLMAN wrote:
> HI again.
> 
> I am going to try my profile again for sending files to see what happens.
> 
> Does the C-wrapper do its own mime encoding/decoding? I see there is a base64 
> file in the CORE part of the library
> 
> Thanks
> wayne
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] Beepcore-c and MIME

[WAYNE I. B. S. <WI...@bl...>]

HI again.

I am going to try my profile again for sending files to see what happens.

Does the C-wrapper do its own mime encoding/decoding? I see there is a base64 
file in the CORE part of the library

Thanks
wayne

Re: [Beepcore-c-users] File transfer

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

I actually rather like the multiple ANS method.   Nice and clean 
in terms of sending large files.  Read a block, send a block, repeat.
Also would make recovery/restart fairly clean if you wanted to implement
that.

Could do either for that matter, MSG/RPY for files you are willing
to read all of into memory, and MSG/ANS*/NUL for large files you 
don't want to slurp in toto.

Also for large file support > 4G you need ANS :)

my 2 cents...

-bill


On Fri, Feb 21, 2003 at 02:53:50PM -0800, Darren New wrote:
> WAYNE IRONS, BLOOMBERG/ SKILLMAN wrote:
> 
> >I'm trying to write a profile which allows for the transfer of files from peer 
> >to peer.  The setup will be "client" attaches to "server", then server sends 
> >files at random.  I am having trouble deciding which is the best method of 
> >exchange style: MSG/RPY where the file is broken as many msg frames or MSG/ANS 
> >where the client says "MSG: send a file" and the server replies with the file in
> > a bunch of "ANS"'s.
> >  
> >
> There's no real reason to send multiple ANS's in this situation. 
> Multiple ANS's are best used when there are multiple independent answers 
> that might be returned in arbitrary orders. If you're getting back 
> exactly one answer, a RPY is appropriate. If you can send a message that 
> says (for example) "send me back all the text files", then mutiple ANS 
> frames would allow the blocks of the different files to be interleaved, 
> so the files can start being sent back as they're found, without one big 
> file holding up many smaller files.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Re: [Beepcore-c-users] File transfer

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

WAYNE IRONS, BLOOMBERG/ SKILLMAN wrote:

>I'm trying to write a profile which allows for the transfer of files from peer 
>to peer.  The setup will be "client" attaches to "server", then server sends 
>files at random.  I am having trouble deciding which is the best method of 
>exchange style: MSG/RPY where the file is broken as many msg frames or MSG/ANS 
>where the client says "MSG: send a file" and the server replies with the file in
> a bunch of "ANS"'s.
>  
>
There's no real reason to send multiple ANS's in this situation. 
Multiple ANS's are best used when there are multiple independent answers 
that might be returned in arbitrary orders. If you're getting back 
exactly one answer, a RPY is appropriate. If you can send a message that 
says (for example) "send me back all the text files", then mutiple ANS 
frames would allow the blocks of the different files to be interleaved, 
so the files can start being sent back as they're found, without one big 
file holding up many smaller files.

[Beepcore-c-users] File transfer

[WAYNE I. B. S. <WI...@bl...>]

Hi all...

I've seen some activity lately on the beepcore list so I know it's still active.
  I didn't get a response on my last plea for assistance, so I thought I'd try 
again.

I'm trying to write a profile which allows for the transfer of files from peer 
to peer.  The setup will be "client" attaches to "server", then server sends 
files at random.  I am having trouble deciding which is the best method of 
exchange style: MSG/RPY where the file is broken as many msg frames or MSG/ANS 
where the client says "MSG: send a file" and the server replies with the file in
 a bunch of "ANS"'s.

Any advice?  Thanks

Re: [Beepcore-c-users] Is beepcore-c still alive? What happened to Huston?

[Huston <hu...@us...>]

> Huston - are you still maintaining the project?

Right now I'm focused on fixing a few things in beepcore-j. When that is
finished I will come back to working on beepcore-c. In the mean time I'm
happy to apply any patches people want to submit (or add them as developers
on the project) or answer any questions.

--Huston

Re: [Beepcore-c-users] Is beepcore-c still alive? What happened to Huston?

[Wolfgang S. <ws...@q-...>]

Jonas -

thanks for the information. So I guess the only remaining 'advantage' of=20
beepcore-c is the license, in case someone wants to use it in a proprietary=
=20
product.
I'm assuming that CodeFactory offers the roadrunner sources under another=20
license for a fee (so that it can be used in a proprietary product), so=20
probably you don't want to switch to an X11/Apache type of license, correct?

I'm not sure whether that is important to me at all, since I am writing Fre=
e=20
Software. However, especially for a library, I do prefer an X11 license ove=
r=20
a GPL license.

Regards,
Wolfgang

On Tuesday 18 February 2003 23:33, Jonas Borgstr=F6m wrote:
> On Tue, 2003-02-18 at 20:19, Wolfgang Spraul wrote:
> > Well, I read several things:
> >
> > 1) beepcore-c has a X11 type of license (i.e. can be used in proprietary
> > products) whereas roadrunner has a GPL type of license (i.e. free
> > software only). beepcore-c is in the debian/unstable distribution where=
as
> > roadrunner is not. Would it be a problem to create a debian package for
> > roadrunner? I don't think so.
>
> Hi,
>
> RoadRunner has no official debian packages in the debian unstable
> distribution but the RoadRunner tarballs contain a "debian" subdirectory
> so a simple "dpkg-buildpackage" is all that is needed to generate your
> own debian packages.
>
> > 2) beepcore-c is supposedly "light" (?) and has less dependencies than
> > roadrunner (libxml2?) I read that beepcore-c just hooks into a socket
> > whereas roadrunner manages the complete connection.
>
> RoadRunner depends on glib2 and libxml2 which both are highly portable
> and widely used libraries.
>
> If the libxml2 dependency really is an issue, it should be quite easy to
> rewrite RoadRunner to use the tiny glib2 xml-subset parser (GMarkup).
>
> What do you mean by "just hooks into a socket"?
> RoadRunner can create a new connection, or just use an existing socket.
>
> / Jonas
>
> > Please correct me if I'm wrong.
> >
> > As you can tell, I haven't started actually using the two libraries yet.
> > My current plan is to just start coding my project (a Calendar Access
> > Protocol server and cgi) and initially try both libraries, then make a
> > decision after a few days.
> >
> > Regards,
> > Wolfgang
> >
> > On Tuesday 18 February 2003 17:58, Marshall Rose wrote:
> > > > Hi everybody,
> > > >
> > > > I'm trying to device whether to use beepcore-c or roadrunner for an
> > > > upcoming project.
> > > > I found pros and cons, but I noticed that the last CVS commit in
> > > > beepcore-c happened on Sept 19 last year (bp_wrapper.h). Is anybody
> > > > still working on beepcore-c? Or is beepcore-c simply working well
> > > > enough that one can just use it? Is the BEEP protocol
> > > > sufficiently/completely implemented?
> > > >
> > > > Huston - are you still maintaining the project?
> > >
> > > hi. a couple of things:
> > >
> > > i think that huston is focusing more on the beepcore-java stuff these
> > > days...
> > >
> > > there's a lot of activity on roadrunner, and i don't think it makes a
> > > lot of sense for folks to try to maintain two open source beep
> > > implementations in C....
> > >
> > > so, while i haven't heard from huston in a while, i wouldn't be
> > > surprised to hear folks suggest that we close down beepcore-c...
> > >
> > > can someone make a compelling argument as to some feature that
> > > beepcore-c has that roadrunner doesn't? if so, then we should think
> > > about this further...
> > >
> > > thanks!
> > >
> > > /MTR
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Beepcore-c-users mailing list
> > Bee...@li...
> > https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Re: [Beepcore-c-users] Is beepcore-c still alive? What happened to Huston?

[Jonas <jo...@co...>]

On Tue, 2003-02-18 at 20:19, Wolfgang Spraul wrote:
> Well, I read several things:
>=20
> 1) beepcore-c has a X11 type of license (i.e. can be used in proprietar=
y=20
> products) whereas roadrunner has a GPL type of license (i.e. free softw=
are=20
> only). beepcore-c is in the debian/unstable distribution whereas roadru=
nner=20
> is not. Would it be a problem to create a debian package for roadrunner=
? I=20
> don't think so.

Hi,

RoadRunner has no official debian packages in the debian unstable
distribution but the RoadRunner tarballs contain a "debian" subdirectory
so a simple "dpkg-buildpackage" is all that is needed to generate your
own debian packages.

>=20
> 2) beepcore-c is supposedly "light" (?) and has less dependencies than=20
> roadrunner (libxml2?) I read that beepcore-c just hooks into a socket w=
hereas=20
> roadrunner manages the complete connection.
>=20

RoadRunner depends on glib2 and libxml2 which both are highly portable
and widely used libraries.

If the libxml2 dependency really is an issue, it should be quite easy to
rewrite RoadRunner to use the tiny glib2 xml-subset parser (GMarkup).

What do you mean by "just hooks into a socket"?
RoadRunner can create a new connection, or just use an existing socket.

/ Jonas

> Please correct me if I'm wrong.
>=20
> As you can tell, I haven't started actually using the two libraries yet=
. My=20
> current plan is to just start coding my project (a Calendar Access Prot=
ocol=20
> server and cgi) and initially try both libraries, then make a decision =
after=20
> a few days.
>=20
> Regards,
> Wolfgang
>=20
> On Tuesday 18 February 2003 17:58, Marshall Rose wrote:
> > > Hi everybody,
> > >
> > > I'm trying to device whether to use beepcore-c or roadrunner for an
> > > upcoming project.
> > > I found pros and cons, but I noticed that the last CVS commit in
> > > beepcore-c happened on Sept 19 last year (bp_wrapper.h). Is anybody=
 still
> > > working on beepcore-c? Or is beepcore-c simply working well enough =
that
> > > one can just use it? Is the BEEP protocol sufficiently/completely
> > > implemented?
> > >
> > > Huston - are you still maintaining the project?
> >
> > hi. a couple of things:
> >
> > i think that huston is focusing more on the beepcore-java stuff these
> > days...
> >
> > there's a lot of activity on roadrunner, and i don't think it makes a=
 lot
> > of sense for folks to try to maintain two open source beep implementa=
tions
> > in C....
> >
> > so, while i haven't heard from huston in a while, i wouldn't be surpr=
ised
> > to hear folks suggest that we close down beepcore-c...
> >
> > can someone make a compelling argument as to some feature that beepco=
re-c
> > has that roadrunner doesn't? if so, then we should think about this
> > further...
> >
> > thanks!
> >
> > /MTR
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
--=20
Jonas Borgstr=F6m                  jo...@co...
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 14