Thread: [Beepcore-java-users] message handling
Status: Beta
Brought to you by:
huston
Menu
▾
▴
beepcore-java-users
|
From: Daan H. <daa...@lu...> - 2005-07-05 15:14:09
Attachments:
ChannelImpl.diff
|
LS, A collegue of mine wrote a patch to beepcore-java's ChannelImpl. The issue we had was that it was not possible to not reply to a message and then send a second message from the same peer. The specifications say that it should be possible to send zero (or more) replies, so we felt this patch was legal. Any ideas anybody? -- <insert value="your favorite astute quote" id="sigquote" /> ----------------------------- Daan Hoogland software architect ----------------------------- daa...@lu... 0620442544 www.luminis.nl ----------------------------- <or ref="sigquote" /> |
|
From: William J. M. <wm...@es...> - 2005-07-05 18:17:42
|
You must send a RPY or an ANS/NUL sequence. It is the correct behavior not to process the next MSG before the previous message is completed. -bill On Tue, Jul 05, 2005 at 05:17:49PM +0200, Daan Hoogland wrote: > LS, > > A collegue of mine wrote a patch to beepcore-java's ChannelImpl. The > issue we had was that it was not possible to not reply to a message and > then send a second message from the same peer. The specifications say > that it should be possible to send zero (or more) replies, so we felt > this patch was legal. Any ideas anybody? > > -- > <insert value="your favorite astute quote" id="sigquote" /> > ----------------------------- > Daan Hoogland > software architect > ----------------------------- > daa...@lu... > 0620442544 > www.luminis.nl > ----------------------------- > <or ref="sigquote" /> > > diff -ur beepcore-0.9.08/src/org/beepcore/beep/core/ChannelImpl.java beepcore/src/org/beepcore/beep/core/ChannelImpl.java > --- beepcore-0.9.08/src/org/beepcore/beep/core/ChannelImpl.java 2003-11-18 08:28:46.000000000 +0100 > +++ beepcore/src/org/beepcore/beep/core/ChannelImpl.java 2005-07-05 14:58:31.000000000 +0200 > @@ -351,17 +351,36 @@ > return this.session; > } > > - public void run() { > - MessageMSGImpl m; > - synchronized (recvMSGQueue) { > - m = (MessageMSGImpl) recvMSGQueue.getFirst(); > - synchronized (m) { > - m.setNotified(); > - } > - } > - > - handler.receiveMSG(m); > - } > + /** > + * Handles first unnotified message in received-message-queue by delivering it to the current > + * request handler. The message is set notified. If the queue is empty, or all messages are > + * already notified, nothing is done. > + */ > + public void run() { > + boolean messageFound = false; > + MessageMSGImpl message = null; > + // find unnotified message > + synchronized (recvMSGQueue) { > + for (Iterator messageIter = recvMSGQueue.iterator(); messageIter.hasNext();) { > + MessageMSGImpl currentMessage = (MessageMSGImpl) messageIter.next(); > + // if message has not been handled yet > + if (!currentMessage.isNotified()) { > + currentMessage.setNotified(); > + message = currentMessage; > + messageFound = true; > + break; > + } > + } > + } > + // deliver message to request handler if unnotified message has been found > + if (messageFound) > + handler.receiveMSG(message); > + else > + log.warn("All messages in queue has already been delivered to the request handler"); > + } > + > + > + > > /** > * Sends a message of type MSG. > @@ -485,10 +504,12 @@ > m = (MessageMSGImpl) recvMSGQueue.getLast(); > > if (m.getMsgno() != frame.getMsgno()) { > + // frame does not belong to previous message > m = null; > } > } > > + // if frame belongs to previous message > if (m != null) { > /// Move this code to DataStream... > Iterator i = frame.getPayload(); > @@ -504,24 +525,42 @@ > > return; > } > - > + // else if frame does not belong to previous message > m = new MessageMSGImpl(this, frame.getMsgno(), > new InputDataStream(this)); > > - m.setNotified(); > + // assumption: > + // notified message means message has been delivered to request handler > + // change: > + // disabled statement below and notify message only after it has been > + // retreived from the queue for delivery to the request handler, see run() > + // method > + > + // m.setNotified(); > > Iterator i = frame.getPayload(); > while (i.hasNext()) { > m.getDataStream().add((BufferSegment)i.next()); > } > > + // if frame is last (and here also first!): frame contains complete message > if (frame.isLast()) { > m.getDataStream().setComplete(); > } > - > + > recvMSGQueue.addLast(m); > > - if (recvMSGQueue.size() == 1) { > + // assumption: > + // received-message-queue can contain several messages since a message > + // is only removed if it is of type MESSAGE_TYPE_RPY, MESSAGE_TYPE_ERR or > + // MESSAGE_TYPE_NUL. Messages of type MESSAGE_TYPE_MSG will never be removed > + // from the queue. > + // change: > + // changed statement 'if (recvMSGQueue.size() == 1) {' into > + // 'if (recvMSGQueue.size() > 0) {' > + > + // if message queue contains at least 1 message > + if (recvMSGQueue.size() > 0) { > try { > callbackQueue.execute(this); > } catch (InterruptedException e) { |
|
From: Daan H. <daa...@lu...> - 2005-07-06 08:21:40
|
William J. Mills wrote: >You must send a RPY or an ANS/NUL sequence. It is the correct behavior >not to process the next MSG before the previous message is completed. > > Yes, I found this in the rfc. But, does this mean that it can be send but will remain in queue untill the previous message is sent or does this mean that it is illegal to send a message untill the previous has had a valid reply? And should a BEEP implemetation prevent the second massage being sent? >-bill > >On Tue, Jul 05, 2005 at 05:17:49PM +0200, Daan Hoogland wrote: > > >>LS, >> >>A collegue of mine wrote a patch to beepcore-java's ChannelImpl. The >>issue we had was that it was not possible to not reply to a message and >>then send a second message from the same peer. The specifications say >>that it should be possible to send zero (or more) replies, so we felt >>this patch was legal. Any ideas anybody? >> >> -- <insert value="your favorite astute quote" id="sigquote" /> ----------------------------- Daan Hoogland software architect ----------------------------- daa...@lu... 0620442544 www.luminis.nl ----------------------------- <or ref="sigquote" /> |
|
From: William J. M. <wm...@es...> - 2005-07-06 08:25:54
|
It should be valid to have multiple MSG frames pening waiting for RPY, and they can be delivered to the peer. It's not defined whether an implementation must send all frames pending outbound if the window is not full, but it is the preferred behavior :) I don't know the java implementation, if thats the bug you are fixing, I'd say it is valid. -bill > Yes, I found this in the rfc. But, does this mean that it can be send > but will remain in queue untill the previous message is sent or does > this mean that it is illegal to send a message untill the previous has > had a valid reply? > > And should a BEEP implemetation prevent the second massage being sent? > |
