Re: [livetribe-scm] [562] garden/livetribe-slp/branches/
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Re: [livetribe-scm] [562] garden/livetribe-slp/branches/ |
|
|
SLP UDP and MTU
by Alan.Cabrera
::
Rate this Message:
So it seems that I should truncate the byte array to the MTU size and
set the overflow bit on. I notice that you only do it for UDP SrvRply. Should we also do this for other UDP messages? Should our UA also look for messages that have this bit set and take the appropriate action? Regards, Alan On Oct 16, 2009, at 2:51 PM, Alan D. Cabrera wrote: > Yeah, I remember that now too. Good catch. I'll check that out. > > Let me ask something about UDP and MTU. This only improves the > likelihood of packets making it through, it's not required for > segments that have a low MTU, correct? > > > Regards, > Alan > > On Oct 16, 2009, at 2:00 PM, Simone Bordet wrote: > >> Alan, >> >> did you check that your fix is compatible with the spec ? >> I remember something about an overflow bit to set, etc. >> >> Thanks, >> >> Simon >> >> On Fri, Oct 16, 2009 at 22:30, <maguro@...> wrote: >>> Revision 562 Author maguro Date 2009-10-16 15:30:24 -0500 (Fri, 16 >>> Oct 2009) >>> >>> Log Message >>> >>> LIVETRIBE-72 check MTU before sending >>> >>> Modified Paths >>> >>> garden/livetribe-slp/branches/2.0.x/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/da/UDPSrvRplyPerformer.java >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java >>> >>> Diff >>> >>> Modified: >>> garden/livetribe-slp/branches/2.0.x/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java >>> (561 => 562) >>> >>> --- >>> garden/livetribe-slp/branches/2.0.x/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java 2009-10-15 >>> 23:34:27 UTC (rev 561) >>> +++ >>> garden/livetribe-slp/branches/2.0.x/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java 2009-10-16 >>> 20:30:24 UTC (rev 562) >>> @@ -17,9 +17,12 @@ >>> >>> import java.net.InetSocketAddress; >>> import java.util.List; >>> +import java.util.logging.Logger; >>> >>> import org.livetribe.slp.ServiceInfo; >>> import org.livetribe.slp.ServiceURL; >>> +import org.livetribe.slp.settings.Defaults; >>> +import org.livetribe.slp.settings.Keys; >>> import org.livetribe.slp.settings.Settings; >>> import org.livetribe.slp.spi.msg.AttributeListExtension; >>> import org.livetribe.slp.spi.msg.IdentifierExtension; >>> @@ -36,19 +39,40 @@ >>> */ >>> public class UDPSrvRplyPerformer >>> { >>> + protected final Logger logger = >>> Logger.getLogger(getClass().getName()); >>> + private int maxTransmissionUnit = >>> Defaults.get(Keys.MAX_TRANSMISSION_UNIT_KEY); >>> private final UDPConnector udpConnector; >>> >>> public UDPSrvRplyPerformer(UDPConnector udpConnector, Settings >>> settings) >>> { >>> this.udpConnector = udpConnector; >>> + if (settings != null) setSettings(settings); >>> } >>> >>> + private void setSettings(Settings settings) >>> + { >>> + if (settings.containsKey(Keys.MAX_TRANSMISSION_UNIT_KEY)) >>> + >>> setMaxTransmissionUnit >>> (settings.get(Keys.MAX_TRANSMISSION_UNIT_KEY)); >>> + } >>> + >>> + public void setMaxTransmissionUnit(int maxTransmissionUnit) >>> + { >>> + this.maxTransmissionUnit = maxTransmissionUnit; >>> + } >>> + >>> public void perform(InetSocketAddress remoteAddress, >>> ServiceAgentInfo >>> serviceAgent, Message message, List<? extends ServiceInfo> services) >>> { >>> - // TODO: must be sure to fit the MTU in case of many >>> services >>> SrvRply srvRply = newSrvRply(serviceAgent, message, >>> services); >>> byte[] bytes = srvRply.serialize(); >>> - udpConnector.unicastSend(serviceAgent.getHost(), >>> remoteAddress, >>> bytes); >>> + >>> + if (bytes.length <= maxTransmissionUnit) >>> + { >>> + udpConnector.unicastSend(serviceAgent.getHost(), >>> remoteAddress, >>> bytes); >>> + } >>> + else >>> + { >>> + logger.finer("Reply not sent, message bigger than >>> maxTransmissionUnit"); >>> + } >>> } >>> >>> private SrvRply newSrvRply(ServiceAgentInfo serviceAgent, Message >>> message, List<? extends ServiceInfo> services) >>> >>> Modified: >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/da/UDPSrvRplyPerformer.java >>> (561 => 562) >>> >>> --- >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/da/UDPSrvRplyPerformer.java 2009-10-15 >>> 23:34:27 UTC (rev 561) >>> +++ >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/da/UDPSrvRplyPerformer.java 2009-10-16 >>> 20:30:24 UTC (rev 562) >>> @@ -17,31 +17,57 @@ >>> >>> import java.net.InetSocketAddress; >>> import java.util.List; >>> +import java.util.logging.Level; >>> +import java.util.logging.Logger; >>> >>> import org.livetribe.slp.ServiceInfo; >>> +import org.livetribe.slp.settings.Defaults; >>> +import org.livetribe.slp.settings.Keys; >>> import org.livetribe.slp.settings.Settings; >>> import org.livetribe.slp.spi.SrvRplyPerformer; >>> import org.livetribe.slp.spi.msg.Message; >>> import org.livetribe.slp.spi.msg.SrvRply; >>> import org.livetribe.slp.spi.net.UDPConnector; >>> >>> + >>> /** >>> * @version $Revision$ $Date$ >>> */ >>> public class UDPSrvRplyPerformer extends SrvRplyPerformer >>> { >>> + protected final Logger logger = >>> Logger.getLogger(getClass().getName()); >>> + private int maxTransmissionUnit = >>> Defaults.get(Keys.MAX_TRANSMISSION_UNIT_KEY); >>> private final UDPConnector udpConnector; >>> >>> public UDPSrvRplyPerformer(UDPConnector udpConnector, Settings >>> settings) >>> { >>> this.udpConnector = udpConnector; >>> + if (settings != null) setSettings(settings); >>> } >>> >>> + private void setSettings(Settings settings) >>> + { >>> + if (settings.containsKey(Keys.MAX_TRANSMISSION_UNIT_KEY)) >>> + >>> setMaxTransmissionUnit >>> (settings.get(Keys.MAX_TRANSMISSION_UNIT_KEY)); >>> + } >>> + >>> + public void setMaxTransmissionUnit(int maxTransmissionUnit) >>> + { >>> + this.maxTransmissionUnit = maxTransmissionUnit; >>> + } >>> + >>> public void perform(InetSocketAddress localAddress, >>> InetSocketAddress >>> remoteAddress, Message message, List<? extends ServiceInfo> >>> services) >>> { >>> - // TODO: must be sure to fit the MTU in case of many >>> services >>> SrvRply srvRply = newSrvRply(message, services); >>> byte[] bytes = srvRply.serialize(); >>> - >>> udpConnector.send(localAddress.getAddress().getHostAddress(), >>> remoteAddress, bytes); >>> + >>> + if (bytes.length <= maxTransmissionUnit) >>> + { >>> + >>> udpConnector.send(localAddress.getAddress().getHostAddress(), >>> remoteAddress, bytes); >>> + } >>> + else >>> + { >>> + logger.finer("Reply not sent, message bigger than >>> maxTransmissionUnit"); >>> + } >>> } >>> } >>> >>> Modified: >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java >>> (561 => 562) >>> >>> --- >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java 2009-10-15 >>> 23:34:27 UTC (rev 561) >>> +++ >>> garden/livetribe-slp/sandbox/osgi/core/src/main/java/org/livetribe/ >>> slp/spi/sa/UDPSrvRplyPerformer.java 2009-10-16 >>> 20:30:24 UTC (rev 562) >>> @@ -17,8 +17,11 @@ >>> >>> import java.net.InetSocketAddress; >>> import java.util.List; >>> +import java.util.logging.Logger; >>> >>> import org.livetribe.slp.ServiceInfo; >>> +import org.livetribe.slp.settings.Defaults; >>> +import org.livetribe.slp.settings.Keys; >>> import org.livetribe.slp.settings.Settings; >>> import org.livetribe.slp.spi.SrvRplyPerformer; >>> import org.livetribe.slp.spi.msg.IdentifierExtension; >>> @@ -31,16 +34,29 @@ >>> */ >>> public class UDPSrvRplyPerformer extends SrvRplyPerformer >>> { >>> + protected final Logger logger = >>> Logger.getLogger(getClass().getName()); >>> + private int maxTransmissionUnit = >>> Defaults.get(Keys.MAX_TRANSMISSION_UNIT_KEY); >>> private final UDPConnector udpConnector; >>> >>> public UDPSrvRplyPerformer(UDPConnector udpConnector, Settings >>> settings) >>> { >>> this.udpConnector = udpConnector; >>> + if (settings != null) setSettings(settings); >>> } >>> >>> + private void setSettings(Settings settings) >>> + { >>> + if (settings.containsKey(Keys.MAX_TRANSMISSION_UNIT_KEY)) >>> + >>> setMaxTransmissionUnit >>> (settings.get(Keys.MAX_TRANSMISSION_UNIT_KEY)); >>> + } >>> + >>> + public void setMaxTransmissionUnit(int maxTransmissionUnit) >>> + { >>> + this.maxTransmissionUnit = maxTransmissionUnit; >>> + } >>> + >>> public void perform(InetSocketAddress localAddress, >>> InetSocketAddress >>> remoteAddress, ServiceAgentInfo serviceAgent, Message message, >>> List<? >>> extends ServiceInfo> services) >>> { >>> - // TODO: must be sure to fit the MTU in case of many >>> services >>> SrvRply srvRply = newSrvRply(message, services); >>> if (serviceAgent.getIdentifier() != null) >>> { >>> @@ -48,6 +64,13 @@ >>> srvRply.addExtension(identifierExtension); >>> } >>> byte[] bytes = srvRply.serialize(); >>> - >>> udpConnector.send(localAddress.getAddress().getHostAddress(), >>> remoteAddress, bytes); >>> + if (bytes.length <= maxTransmissionUnit) >>> + { >>> + >>> udpConnector.send(localAddress.getAddress().getHostAddress(), >>> remoteAddress, bytes); >>> + } >>> + else >>> + { >>> + logger.finer("Reply not sent, message bigger than >>> maxTransmissionUnit"); >>> + } >>> } >>> } >>> >>> ________________________________ >>> >>> To unsubscribe from this list please visit: >>> >>> http://xircles.codehaus.org/manage_email >> >> >> >> -- >> http://bordet.blogspot.com >> --- >> Finally, no matter how good the architecture and design are, >> to deliver bug-free software with optimal performance and >> reliability, >> the implementation technique must be flawless. Victoria Livschitz >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: SLP UDP and MTU
by simonebordet
::
Rate this Message:
Hi,
On Sat, Oct 17, 2009 at 04:21, Alan D. Cabrera <adc@...> wrote: > So it seems that I should truncate the byte array to the MTU size and set > the overflow bit on. But I think the way you do it is wrong ? You cannot truncate in the middle of the bytes since otherwise the client will choke. I have a better fix for this in trunk, which I can backport to the branch, hopefully. Simon -- http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: SLP UDP and MTU
by Alan.Cabrera
::
Rate this Message:
On Oct 19, 2009, at 1:41 AM, Simone Bordet wrote: > Hi, > > On Sat, Oct 17, 2009 at 04:21, Alan D. Cabrera <adc@...> > wrote: >> So it seems that I should truncate the byte array to the MTU size >> and set >> the overflow bit on. > > But I think the way you do it is wrong ? > You cannot truncate in the middle of the bytes since otherwise the > client will choke. Are you sure? Does OpenSLP choke or is it just our clients that will choke? The spec says a vague truncate. > I have a better fix for this in trunk, which I can backport to the > branch, hopefully. At first glance I see a lot of serializing and deserializing going on. Strikes me as odd. Can you explain what's going on? Regards, Alan --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: SLP UDP and MTU
by simonebordet
::
Rate this Message:
Hi,
On Mon, Oct 19, 2009 at 18:31, Alan D. Cabrera <adc@...> wrote: > > On Oct 19, 2009, at 1:41 AM, Simone Bordet wrote: > >> Hi, >> >> On Sat, Oct 17, 2009 at 04:21, Alan D. Cabrera <adc@...> >> wrote: >>> >>> So it seems that I should truncate the byte array to the MTU size and set >>> the overflow bit on. >> >> But I think the way you do it is wrong ? >> You cannot truncate in the middle of the bytes since otherwise the >> client will choke. > > Are you sure? Does OpenSLP choke or is it just our clients that will choke? > The spec says a vague truncate. > >> I have a better fix for this in trunk, which I can backport to the >> branch, hopefully. > > At first glance I see a lot of serializing and deserializing going on. > Strikes me as odd. Can you explain what's going on? Take for example AttrRply. Its format says 2 bytes for error code, 2 bytes for length, then a variable length bytes for the attributes. Say the attribute length, once serialized, is 2073 bytes. Say MTU is 1400 You cannot truncate the packet with 00 - error code 2073 - length 1396 bytes - attributes where 1396 == 1400 - 2 bytes for error code - 2 bytes for length (let's ignore the message header for now). Note that you cannot say "I wait for the next message then read the rest", as the next message via UDP may not arrive, or be another unrelated one. The spec says that if you see an overflow message, you can connect via TCP, or use what's in the message, but that content of the message should be syntactically correct. That's my interpretation. I don't recall if OpenSLP handles overflow at all, will check. Simon -- http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: SLP UDP and MTU
by Alan.Cabrera
::
Rate this Message:
On Oct 19, 2009, at 10:43 AM, Simone Bordet wrote: > Hi, > > On Mon, Oct 19, 2009 at 18:31, Alan D. Cabrera <adc@...> > wrote: >> >> On Oct 19, 2009, at 1:41 AM, Simone Bordet wrote: >> >>> Hi, >>> >>> On Sat, Oct 17, 2009 at 04:21, Alan D. Cabrera <adc@...> >>> wrote: >>>> >>>> So it seems that I should truncate the byte array to the MTU size >>>> and set >>>> the overflow bit on. >>> >>> But I think the way you do it is wrong ? >>> You cannot truncate in the middle of the bytes since otherwise the >>> client will choke. >> >> Are you sure? Does OpenSLP choke or is it just our clients that >> will choke? >> The spec says a vague truncate. >> >>> I have a better fix for this in trunk, which I can backport to the >>> branch, hopefully. >> >> At first glance I see a lot of serializing and deserializing going >> on. >> Strikes me as odd. Can you explain what's going on? > > Take for example AttrRply. Its format says 2 bytes for error code, 2 > bytes for length, then a variable length bytes for the attributes. > > Say the attribute length, once serialized, is 2073 bytes. Say MTU is > 1400 > > You cannot truncate the packet with > 00 - error code > 2073 - length > 1396 bytes - attributes > > where 1396 == 1400 - 2 bytes for error code - 2 bytes for length > (let's ignore the message header for now). > > Note that you cannot say "I wait for the next message then read the > rest", as the next message via UDP may not arrive, or be another > unrelated one. > The spec says that if you see an overflow message, you can connect via > TCP, or use what's in the message, but that content of the message > should be syntactically correct. > > That's my interpretation. Yeah, it's vague but I think your interpretation is the safer one. But my question was that the implementation that we have now constantly serialize and de-serialize. This strikes me as a bit of overkill. I was wondering if the message POJOs and their elements already know their byte sizes a priori and just have method called byteSize(). Regards, Alan Regards, Alan --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free embeddable forum powered by Nabble | Forum Help |
