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

Re: [Beepcore-c-users] BEEPD clashes in Solaris 2.6

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

There might be a couple of different threading options on Solaris.
The code used to compile there, but I am not sure if anyone has in 
a while.  Can you see what threading you have available and perhaps
reconfigure to native from posix threads for example?  This might
solve it.

-bill


On Fri, Oct 31, 2003 at 03:51:42PM +0800, Guan Wee LOO wrote:
> Hi,
> I  managed to compiled the BEEPCORE-c implementation and its beepd
> sample listener program (but only after disabling the logging feature,
> can anyone tell me how without doing this?).  Initially, everything
> seemed fine but the program hanged and crashed after about the 4th BEEP
> connection (from a BEEP client using the echo profile).  I am testing
> with the null-echo profile that comes with the samples. It seems that
> the problem lies with the SEM_WAIT call in the fiostate_unblock_write
> function (bp_fiostate.c)- it hangs at this point. I am using the
> libposix4 library. Is there anyone who manage to compile and run the
> samples successfully in Solaris 2.x without encountering any problem?
> Please let me know. Thanks.
>  
> Regards,
> Guan Wee

[Beepcore-c-users] BEEPD clashes in Solaris 2.6

[Guan W. L. <gua...@ap...>]

Hi,
I  managed to compiled the BEEPCORE-c implementation and its beepd
sample listener program (but only after disabling the logging feature,
can anyone tell me how without doing this?).  Initially, everything
seemed fine but the program hanged and crashed after about the 4th BEEP
connection (from a BEEP client using the echo profile).  I am testing
with the null-echo profile that comes with the samples. It seems that
the problem lies with the SEM_WAIT call in the fiostate_unblock_write
function (bp_fiostate.c)- it hangs at this point. I am using the
libposix4 library. Is there anyone who manage to compile and run the
samples successfully in Solaris 2.x without encountering any problem?
Please let me know. Thanks.
=20
Regards,
Guan Wee

[Beepcore-c-users] Re: Listener in CLOSE_WAIT (Darren New)

[Guan W. L. <gua...@ap...>]

The problem is  they remain in CLOSE_WAIT without clearing up at all. By
the way the listener is running in RH Linux 7.2.

Rgds,
Guan Wee
-----Original Message-----
From: bee...@li...
[mailto:bee...@li...]=20
Sent: Saturday, October 25, 2003 11:05 AM
To: bee...@li...
Subject: Beepcore-c-users digest, Vol 1 #115 - 1 msg


Send Beepcore-c-users mailing list submissions to
	bee...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
or, via email, send a message with subject or body 'help' to
	bee...@li...

You can reach the person managing the list at
	bee...@li...

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Beepcore-c-users digest..."


Today's Topics:

   1. Re: Listener in CLOSE_WAIT (Darren New)

--__--__--

Message: 1
Date: Thu, 23 Oct 2003 11:02:24 -0700
From: Darren New <dn...@sa...>
To: Guan Wee LOO <gua...@ap...>
CC: bee...@li...
Subject: Re: [Beepcore-c-users] Listener in CLOSE_WAIT

Guan Wee LOO wrote:
> "netstat -an" will show all the TCP/IP states in CLOSE_WAIT.

CLOSE_WAIT is a TCP state where the socket is closed, but the kernel is=20
keeping around enough information to properly handle packets that might=20
have been duplicated and then delayed in the network. It prevents a new=20
connection to the socket from accidentally getting confused with a=20
closed connection. CLOSE_WAIT should clear up within 256 seconds of the=20
actual close, all by itself.

--=20
Darren New, San Diego CA USA (PST)
"He's just a skinhead with a bad haircut."





--__--__--

_______________________________________________
Beepcore-c-users mailing list Bee...@li...
https://lists.sourceforge.net/lists/listinfo/beepcore-c-users


End of Beepcore-c-users Digest

Re: [Beepcore-c-users] Listener in CLOSE_WAIT

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

Guan Wee LOO wrote:
> "netstat -an" will show all the TCP/IP states in CLOSE_WAIT.

CLOSE_WAIT is a TCP state where the socket is closed, but the kernel is 
keeping around enough information to properly handle packets that might 
have been duplicated and then delayed in the network. It prevents a new 
connection to the socket from accidentally getting confused with a 
closed connection. CLOSE_WAIT should clear up within 256 seconds of the 
actual close, all by itself.

-- 
Darren New, San Diego CA USA (PST)
"He's just a skinhead with a bad haircut."

Re: [Beepcore-c-users] Listener in CLOSE_WAIT

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

Unless they stay in CLOSE_WAIT forever, that's normal.....  


On Wed, Oct 22, 2003 at 10:39:27AM +0800, Guan Wee LOO wrote:
> Hi,
> I am using the ECHO example. The server is running the BEEPCORE-C
> implementation as a listener while the client is running the
> BEEPCORE-JAVA implementation. It seems that the server does not close
> and release the TCP/IP connection after the client session is closed. A
> "netstat -an" will show all the TCP/IP states in CLOSE_WAIT. Where is
> the problem. Please advise. Thanks.
> 
> Rgds
> Guan Wee

[Beepcore-c-users] Listener in CLOSE_WAIT

[Guan W. L. <gua...@ap...>]

Hi,
I am using the ECHO example. The server is running the BEEPCORE-C
implementation as a listener while the client is running the
BEEPCORE-JAVA implementation. It seems that the server does not close
and release the TCP/IP connection after the client session is closed. A
"netstat -an" will show all the TCP/IP states in CLOSE_WAIT. Where is
the problem. Please advise. Thanks.

Rgds
Guan Wee

Re: [Beepcore-c-users] Connection-level initialization on initiator side?

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

I think so, yes.... pro_connection_init...

On Tue, Oct 14, 2003 at 12:06:17PM -0400, David C Niemi wrote:
> 
> I need to do non-channel-specific initialization on the initiator side.  
> What is the best place for this?  As far as I can tell pro_session_init() 
> only happens on the Listener side, though perhaps pro_connection_init() is 
> what I am looking for, perhaps called on BOTH sides, and I can check 
> bp->role?
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] Connection-level initialization on initiator side?

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

I need to do non-channel-specific initialization on the initiator side.  
What is the best place for this?  As far as I can tell pro_session_init() 
only happens on the Listener side, though perhaps pro_connection_init() is 
what I am looking for, perhaps called on BOTH sides, and I can check 
bp->role?

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

Re: [Beepcore-c-users] bpc_send semantics and per-channel application-specific data?

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

nope....  but that could probably be stuffed into a list
held in the channel info pointer...  You'd have to scan your own
data structure.  Gets even more complicated when you think about how to
handle ANS frames....

-bill

On Sun, Oct 12, 2003 at 12:03:42AM -0400, David C Niemi wrote:
> >  lemme just drop in the appropraite header file section here...  bp_wrapper.h
> > 
> > You hafta maintain the data yourself, but you can associate it with the 
> > channel.
> ...
> > extern void* bpc_get_channel_info(struct CHANNEL_INSTANCE *inst);
> ...
> > extern void bpc_set_channel_info(struct CHANNEL_INSTANCE *inst,
> > 				  void *data);
> 
> Excellent!  Anything like this available on a per-message basis?  For 
> large messages, or when frames get fragmented, messages can make quite a 
> few passes through pro_frame_available() and info about them has to be 
> remembered somewhere.  I suppose it is possible that the beepcore code 
> doesn't even have any per-message data structures to hang a pointer in, 
> though, as it is really only the application that is going to care much 
> about message-level stuff.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Re: [Beepcore-c-users] bpc_send semantics and per-channel application-specific data?

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

>  lemme just drop in the appropraite header file section here...  bp_wrapper.h
> 
> You hafta maintain the data yourself, but you can associate it with the 
> channel.
...
> extern void* bpc_get_channel_info(struct CHANNEL_INSTANCE *inst);
...
> extern void bpc_set_channel_info(struct CHANNEL_INSTANCE *inst,
> 				  void *data);

Excellent!  Anything like this available on a per-message basis?  For 
large messages, or when frames get fragmented, messages can make quite a 
few passes through pro_frame_available() and info about them has to be 
remembered somewhere.  I suppose it is possible that the beepcore code 
doesn't even have any per-message data structures to hang a pointer in, 
though, as it is really only the application that is going to care much 
about message-level stuff.

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

Re: [Beepcore-c-users] bpc_send semantics and per-channel application-specific data?

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

On Fri, Oct 10, 2003 at 11:50:50AM -0700, Darren New wrote:
> David C Niemi wrote:
> > I noticed that buffers are generally copied before calling bpc_send().  
> > Why is this necessary, and are there circumstances under which it may be 
> > omitted?
> 
> The core part of the protocol doesn't copy the data around. You ask the 
> core for a frame to store the data in, and the core sends directly from 
> that memory space until it's done. That was the original code, and I 
> haven't looked for a while, and it's possible the higher-level code 
> copies the data into an allocated frame instead of letting you allocate 
> your own, tho. But minimizing copies was one of the (annoying ;-) 
> requirements for the core code.
> 
> William would have to tell you whether the threaded layer copies the data.
> 

Hmmm... don't remember.  I think perhaps we do in some cases since we are
not sure the profile code won't free the data before it's sent, but if you
are using an allocated frame it should do the right thing.

> > I also need to keep some information that is per-channel and per-message 
> > that is application-specific.  Is there any preexisting clean place to put 
> > such things, or do I need to make and maintain my own data structures for 
> > both?
> 
> I don't think there's any such place in the core for doing that, since 
> the core manages its own structures internally. If there were a pointer 
> to data, there would have to be a pointer to the clean-up routine. 
> Actually, I kind of remember doing something like that, but I don't 
> remember if it was for internal or external data. But it should be 
> pretty obvious whether it's in the core data structures or not. They're 
> not that complicated. :-)
> 
> 
 lemme just drop in the appropraite header file section here...  bp_wrapper.h

You hafta maintain the data yourself, but you can associate it with the 
channel.

/*
 * Accessor function to allow the application or profile to retrieve an 
 * arbitrary pointer stored in the channel instace.
 *
 * @param inst A pointer to the channel-instance structure.
 *
 * @return The most recent pointer passed to 
 * {@link bpc_set_channel_info bpc_set_channel_info} for this channel.
 **/
extern void* bpc_get_channel_info(struct CHANNEL_INSTANCE *inst);

/*
 * Accessor function to allow the application or profile to store an 
 * arbitrary pointer with the channel instace.
 *
 * @param inst A pointer to the channel-instance structure.
 *
 * @param data An arbitrary pointer provided by the application.
 **/
extern void bpc_set_channel_info(struct CHANNEL_INSTANCE *inst,
				  void *data);

-bill

Re: [Beepcore-c-users] bpc_send semantics and per-channel application-specific data?

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

David C Niemi wrote:
> I noticed that buffers are generally copied before calling bpc_send().  
> Why is this necessary, and are there circumstances under which it may be 
> omitted?

The core part of the protocol doesn't copy the data around. You ask the 
core for a frame to store the data in, and the core sends directly from 
that memory space until it's done. That was the original code, and I 
haven't looked for a while, and it's possible the higher-level code 
copies the data into an allocated frame instead of letting you allocate 
your own, tho. But minimizing copies was one of the (annoying ;-) 
requirements for the core code.

William would have to tell you whether the threaded layer copies the data.

> I also need to keep some information that is per-channel and per-message 
> that is application-specific.  Is there any preexisting clean place to put 
> such things, or do I need to make and maintain my own data structures for 
> both?

I don't think there's any such place in the core for doing that, since 
the core manages its own structures internally. If there were a pointer 
to data, there would have to be a pointer to the clean-up routine. 
Actually, I kind of remember doing something like that, but I don't 
remember if it was for internal or external data. But it should be 
pretty obvious whether it's in the core data structures or not. They're 
not that complicated. :-)


> 
> William and Darren, thanks again for your previous help.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
> 


-- 
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.

[Beepcore-c-users] bpc_send semantics and per-channel application-specific data?

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

I noticed that buffers are generally copied before calling bpc_send().  
Why is this necessary, and are there circumstances under which it may be 
omitted?

I also need to keep some information that is per-channel and per-message 
that is application-specific.  Is there any preexisting clean place to put 
such things, or do I need to make and maintain my own data structures for 
both?

William and Darren, thanks again for your previous help.

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

Re: [Beepcore-c-users] Which comes first, pro_start_confirmation or pro_start_callback?

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

David C Niemi wrote:
>>I believe one is called on the start-listening peer and the other on the
>>start-initiating peer when start completes.

If I recall correctly, pro_start_callback is called on the initiator of 
the connection, and pro_start_confirmation is called on both sides (on 
the listener when the answer to the start is sent, and on the initiator 
when it's received.) I also believe that pro_start_confirmation imight 
not be called if the request is refused. I.e., the 
pro_start_confirmation tells you it's safe to start sending on the 
channel that's open.

> pro_start_confirmation() is definitily on the initiator side.
> 
> But pro_start_callback() is "invoked when a response is received to 
> *_start's request to start a channel".  This also sounds like the 
> initiator side -- if it had SENT the response, why would it be looking for 
> it?

It's looking for the response. Even if it's a negative response.

It's been too long for me, so you might need to look at the code to see 
exactly what's going on there.

-- 
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] Which comes first, pro_start_confirmation or pro_start_callback?

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

On Thu, 2 Oct 2003, William J. Mills wrote:
> > I was noticing that pro_start_confirmation() and pro_start_callback() 
> > sound mighty similar.  It sounds like the pro_start_confirmation() may be 
> > slightly later, but if so I'm curious what the distinction is between the 
> > two.  In other words, once a response is received to a request to start a 
> > channel, what remains to be done before the channel is actually considered 
> > to have started?  Is there some local housekeeping first that may take 
> > significant time, or what?
> > 
> 
> I believe one is called on the start-listening peer and the other on the
> start-initiating peer when start completes.

pro_start_confirmation() is definitily on the initiator side.

But pro_start_callback() is "invoked when a response is received to 
*_start's request to start a channel".  This also sounds like the 
initiator side -- if it had SENT the response, why would it be looking for 
it?


> > In a vaguely related question, is there a clean and convenient way to pass
> > a short text string from the channel initiator to the peer for the remote
> > profile to utilize when it is asked to start a channel?  Or it is expected 
> > that any such profile-specific dealings should wait until after the 
> > channel has already started?
> 
> 
> You can add piggyback data on the start request.  Get's passed in 
> to the start routine and can be used in startup.

Thanks.

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

Re: [Beepcore-c-users] Which comes first, pro_start_confirmation or pro_start_callback?

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

On Thu, Oct 02, 2003 at 05:24:46PM -0400, David C Niemi wrote:
> 
> I was noticing that pro_start_confirmation() and pro_start_callback() 
> sound mighty similar.  It sounds like the pro_start_confirmation() may be 
> slightly later, but if so I'm curious what the distinction is between the 
> two.  In other words, once a response is received to a request to start a 
> channel, what remains to be done before the channel is actually considered 
> to have started?  Is there some local housekeeping first that may take 
> significant time, or what?
> 

I believe one is called on the start-listening peer and the other on the
start-initiating peer when start completes.

> 
> In a vaguely related question, is there a clean and convenient way to pass
> a short text string from the channel initiator to the peer for the remote
> profile to utilize when it is asked to start a channel?  Or it is expected 
> that any such profile-specific dealings should wait until after the 
> channel has already started?


You can add piggyback data on the start request.  Get's passed in 
to the start routine and can be used in startup.


-bill

[Beepcore-c-users] Which comes first, pro_start_confirmation or pro_start_callback?

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

I was noticing that pro_start_confirmation() and pro_start_callback() 
sound mighty similar.  It sounds like the pro_start_confirmation() may be 
slightly later, but if so I'm curious what the distinction is between the 
two.  In other words, once a response is received to a request to start a 
channel, what remains to be done before the channel is actually considered 
to have started?  Is there some local housekeeping first that may take 
significant time, or what?


In a vaguely related question, is there a clean and convenient way to pass
a short text string from the channel initiator to the peer for the remote
profile to utilize when it is asked to start a channel?  Or it is expected 
that any such profile-specific dealings should wait until after the 
channel has already started?

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

Re: [Beepcore-c-users] Message timeouts?

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

It has been a while since I looked at the code but I thought that socket
errors were checked after returning from poll(). Though I'm not sure if the
information is propagated up to the channels and profiles. If not, it should
be a fairly straight forward change.

--Huston

----- Original Message ----- 
From: "William J. Mills" <wm...@es...>
To: "Andy Dent" <de...@oo...>
Cc: <bee...@li...>
Sent: Monday, September 29, 2003 3:06 PM
Subject: Re: [Beepcore-c-users] Message timeouts?


> An out of sequence reply will cause an error in the core, I think.
>
> Beyond that, no... there is not a mechanism for timeout.  That's
> left to the application level to deal with (profile).
>
> -bill
>
>
> On Sun, Sep 28, 2003 at 06:50:07PM +0800, Andy Dent wrote:
> > Does beepcore-c handle the issue of message timeouts, ie: if a client
> > receiving regular messages has stopped responding or if a sloppily
> > written client never responds?
> >
> > I can't find any discussion of it other than a message by Helen Ryan
> > back in January which didn't seem to get a response
> >
> > "
> > >What if the server just doesn't reply, e.g. due to programming error,
etc?
> > >  This would also cause beepng to hang forever.  Where the client is
part of a
> > >  larger system or long-running program, this can be a problem.  Should
there
> > >  not be some kind of timeout?  Is this intentional in the BEEP
protocol or
> > >  just an implementation issue?
> > "
> > -- 
> >
> > 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
> >
> >
> > -------------------------------------------------------
> > 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
>
>
> -------------------------------------------------------
> 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] Message timeouts?

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

An out of sequence reply will cause an error in the core, I think.

Beyond that, no... there is not a mechanism for timeout.  That's 
left to the application level to deal with (profile).

-bill


On Sun, Sep 28, 2003 at 06:50:07PM +0800, Andy Dent wrote:
> Does beepcore-c handle the issue of message timeouts, ie: if a client 
> receiving regular messages has stopped responding or if a sloppily 
> written client never responds?
> 
> I can't find any discussion of it other than a message by Helen Ryan 
> back in January which didn't seem to get a response
> 
> "
> >What if the server just doesn't reply, e.g. due to programming error, etc?
> >  This would also cause beepng to hang forever.  Where the client is part of a
> >  larger system or long-running program, this can be a problem.  Should there
> >  not be some kind of timeout?  Is this intentional in the BEEP protocol or
> >  just an implementation issue?
> "
> -- 
> 
> 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
> 
> 
> -------------------------------------------------------
> 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] Message timeouts?

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

On Sun, 28 Sep 2003, Andy Dent wrote:
> Does beepcore-c handle the issue of message timeouts, ie: if a client 
> receiving regular messages has stopped responding or if a sloppily 
> written client never responds?
> 
> I can't find any discussion of it other than a message by Helen Ryan 
> back in January which didn't seem to get a response

As I understand it, beepcore-c has no timers, so it is up to the
application to decide what to do if its peer stops responding.  I think
this is probably just as well, if you are writing an asynchronous
(nonblocking) sort of application, which beepcore-c seems fairly well
suited for.  I suppose if you want to have a simple app using blocking
calls it might get a bit annoying, as you'd have to set alarms/timers to
wake you up if that blocking call doesn't return in a reasonable amount of
time.

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

[Beepcore-c-users] Message timeouts?

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

Does beepcore-c handle the issue of message timeouts, ie: if a client 
receiving regular messages has stopped responding or if a sloppily 
written client never responds?

I can't find any discussion of it other than a message by Helen Ryan 
back in January which didn't seem to get a response

"
>What if the server just doesn't reply, e.g. due to programming error, etc?
>  This would also cause beepng to hang forever.  Where the client is part of a
>  larger system or long-running program, this can be a problem.  Should there
>  not be some kind of timeout?  Is this intentional in the BEEP protocol or
>  just an implementation issue?
"
-- 

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] Unnecessary Frame Fragmentation using beepcore-c -- More Info

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

The initial diagnosis of this problem seems to be wrong.  We had thought
that the receiver did not have time to digest frames fast enough to keep
its window open, and the sender was trying to squeeze a partial frame
through as soon as any space opened up.

I implemented William Mills' suggestion, which was to have the sending
profile verify that enough window space is available in the (receiving)  
peer before sending.  However, it turns out that generally there is plenty
of window space but fragmentation occurs anyway!  And in the rare case
when the receive window is too full for a full frame, waiting until it
isn't so full still doesn't prevent fragmentation.

I am not quite sure what it means, but in further tests I found that
increasing the window size to 64K results in a bit of fragmentation only
for a few frames every 64K of message.  It seems as though having
previously sent smaller frames in a previous message has fragmented some
buffer space somewhere, and it is never getting consolidated.  So I would
now guess that this is an actual bug in the vicinity of CBEEP.c, and not
merely a tuning issue.  I verified that the receiver frees each frame with 
bpc_frame_destroy() after it reads it.

DCN

On Wed, 17 Sep 2003, David C Niemi wrote:
> As I started this whole discussion, I'll try to summarize it:
> 
> I have an application sending potentially large messages over a small
> number of channels (at the moment just one).  The large messages are sent
> rapidly (not waiting for per-frame acks) in max frame size (4K) chunks,
> which tends to fill up the peer application's receive window.  At that
> point the low-level (CBEEP.c) code tries to send whatever will fit into
> the peer's receive window, which is usually a tiny fragment of one of the
> 4K frames.  Each time the receiver reads a small frame fragment, it frees
> up a small part of its receive window, and another small frame is sent to
> make use of the new space.  Thus the system settles into a pattern of
> sending fragments for the entire large message, resulting in far more
> frames sent and read by the receiver, hurting performance.
> 
> The proposed solution is to let the sending application detect the peer's
> current receive window size, and to potentially hold off on sending the 4K
> frames until at least that much space is available, based on
> application-level logic.  I expect that a very small amount of delay by
> the sender will permit getting into a pattern of full-sized frames and
> thus result in better performance.  William Mills is looking into a clean 
> way to expose the peer's window size at the application level.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 

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

[Beepcore-c-users] FreeBSD port checked in

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

Just checked in mods to confgure.in aand a few others to 
support FreeBSD.  Thread support is pthreads.  beepng seems 
to run fine.

-bill

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

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

Marshall Rose wrote:

 > the 4k number is the *minimum* guaranteed when a channel starts. it's
 > neither fixed nor an upper-bound...


Nore is it in beepcore-c. It's just that the core itself doesn't modify 
it unless the application requests that.

 >> What would you suggest would be the proper solution to Silly Window 
Syndrome?
 >
 >
 > timers in the internals, plus a flush call in the api...


That's pretty much what we're discussing how to do, yes. We're figuring 
out what needs to be exposed so the application (i.e., wrapper) can 
delay, and then determine if the buffer is empty, so you'd get a kind of 
flush API. But that's outside the core of beepcore-c, and up to the 
wrapper to implement. We're discussing what parts of the core have to be 
exposed to the wrapper to let the wrapper do such a thing.

 > if you look at the uIP code (a tiny tcp stack), that's probably a far
 > better model that what beepcore-c uses now: virtually no
 > os-dependencies, and a well-defined api saying how an application has to
 > behave in order for the state machine to run...


Then the other possibility is to put a "don't fragment" flag in beepcore 
such that if the leading frame to be sent won't fit in the window, the 
core will just return without sending anything, which is basically what 
uIP does. Sounds like an interop nightmare when you start getting 
complex protocols with multiple channels and limited buffer space to not 
deadlock, but if you're in control of the source code for both sides, it 
could be a win, sure. That too should be easy to implement.

If you put this flag in, you wouldn't need timers, you'd just wait for 
the remote side to trigger the sending by sending you a SEQ with a 
sufficiently big window. uIP only uses the timers to trigger 
retransmits, not to control anything to do with fragmentation.

-- 
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?

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

> Uh, no, not really. Firstly, the 4K window isn't what's causing the 
> problem. Secondly, the 4K window's actually specified in RFC3081 3.1.1. 
> If the caller of beepcore wants to bump up the receiving window size, 
> it's easy to do, but it's under control of the caller, since that'll 
> obviously affect how much memory it uses. I don't think we'd want to use 
> your algorithm, for example, on a port to a Z80-based controller that 
> only *has* 64K of memory.
    
great! get beepcore-c running on a z80 and then i'll agree that beepcore-c made
the right design decision...
    
the 4k number is the *minimum* guaranteed when a channel starts. it's
neither fixed nor an upper-bound...
    
    
> What would you suggest would be the proper solution to Silly Window 
> Syndrome?

timers in the internals, plus a flush call in the api...
    
if you look at the uIP code (a tiny tcp stack), that's probably a far
better model that what beepcore-c uses now: virtually no
os-dependencies, and a well-defined api saying how an application has to
behave in order for the state machine to run...
    
/mtr