[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Hub Lessons Learned
- Subject: RE: Hub Lessons Learned
- From: "Patrick Lidstone \(Personal e-mail\)" <patrick@xxxxxxxxxxxx>
- Date: Mon, 25 Oct 2004 16:03:02 +0100
------=_NextPart_000_0008_01C4BAAC.1B877560
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
-----Original Message-----
From: mcs101main@xxxxxxx [mailto:mcs101main@xxxxxxx]
Sent: 25 October 2004 15:40
To: xAP_developer@xxxxxxx
Subject: [xAP_developer] Hub Lessons Learned
In working with a hub implementation on various PCs there are a few
lessons that I have learned and will share for others that have hub
developement interest.
1. It is possible that a PC with LAN card(s) will only show 127.0.0.1
as the only available network. In my case it is a laptop when
disconnected from both the wired and wireless networks. This means that
a hub should route traffic on this interface accordingly. I have found
that a 255.255.255.255 broadcast IP does not function on 127.0.0.1 and
that the target must explicitly be 127.0.0.1. Note that message viewers
also should be cognizant of a 127.0.0.1-only network as well.
Have you tried 0.0.0.0 ? Broadcast can definitely be made to work on
just the loopback interface.
2. It appears that a VPN connection is treated as a virtual interface
that is mapped into the same physical interface as the primary LAN. The
fallout of this is that the interface will report 2 message reception
events for each message received. It does not matter if the VPN
connection is alive or not. Its existance is what creates the problem.
There are also confirmed bugs in some Microsoft Winsock implementations
in which two events are generated on a message reception. I handled the
VPN situation by not forwarding any duplicate reception within a 100
millisecond window.
I have a variety of VPN clients installed, under Win2K, and I've never
seen this behaviour. I'm not saying it can't happen, just that I haven't
seen it... We could add an auto-incrementing sequence number to messages
at source if this turns out to be a widespread problem.
I suspect that other computers will exhibit unanticipated behaviors and
each needs to be dealt with on a case-by-case basis to understand what a
hub must do to accomdate.
Patrick
------=_NextPart_000_0008_01C4BAAC.1B877560
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=us-ascii">
<TITLE>Message</TITLE>
<!-- BEGIN WEBMAIL STATIONERY -->
<STYLE type=text/css>P {
MARGIN: 0px
}
</STYLE>
<META content="MSHTML 6.00.2800.1476"
name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff
size=2></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px
solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr
align=left><FONT
face=Tahoma size=2>-----Original
Message-----<BR><B>From:</B>
mcs101main@xxxxxxx [mailto:mcs101main@xxxxxxx]
<BR><B>Sent:</B> 25 October
2004 15:40<BR><B>To:</B>
xAP_developer@xxxxxxx<BR><B>Subject:</B>
[xAP_developer] Hub Lessons
Learned<BR><BR></FONT></DIV><!-- WEBMAIL
STATIONERY noneset -->
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px
solid">
<P>In working with a hub implementation on various PCs there are a
few
lessons that I have learned and will share for others that have hub
developement interest.</P>
<P> </P>
<P>1. It is possible that a PC with LAN card(s) will only
show
127.0.0.1 as the only available network. In my case it is a
laptop
when disconnected from both the wired and wireless networks. This
means that a hub should route traffic on this interface
accordingly. I
have found that a 255.255.255.255 broadcast IP does not function on
127.0.0.1 and that the target must explicitly be
127.0.0.1.
Note that message viewers also should be cognizant of a 127.0.0.1-only
network as well.</P>
<P><FONT face=Arial color=#0000ff
size=2></FONT> </P>
<P><FONT face=Arial color=#0000ff size=2><SPAN
class=394590015-25102004>Have
you tried 0.0.0.0 ? Broadcast can definitely be made to work on just the
loopback interface.</SPAN></FONT></P>
<P><FONT face=Arial color=#0000ff
size=2></FONT> </P>
<P>2. It appears that a VPN connection is treated as a virtual
interface
that is mapped into the same physical interface as the primary
LAN.
The fallout of this is that the interface will report 2 message
reception events for each message received. It does not matter if
the
VPN connection is alive or not. Its existance is what creates the
problem. There are also confirmed bugs in some Microsoft Winsock
implementations in which two events are generated on a message
reception. I handled the VPN situation by not
forwarding any duplicate reception within a 100 millisecond
window.<SPAN class=394590015-25102004><FONT face=Arial
color=#0000ff
size=2> </FONT></SPAN></P>
<P><SPAN class=394590015-25102004><FONT face=Arial
color=#0000ff
size=2></FONT></SPAN> </P>
<P><SPAN class=394590015-25102004><FONT face=Arial
color=#0000ff size=2>I
have a variety of VPN clients installed, under
Win2K, and
I've never seen this behaviour. I'm not saying it can't happen,
just
that I haven't seen it... We could add an auto-incrementing sequence number
to messages at source if this turns out to be a widespread
problem.</FONT> </SPAN></P>
<P><FONT face=Arial color=#0000ff
size=2></FONT> </P>
<P>I suspect that other computers will exhibit unanticipated
behaviors and
each needs to be dealt with on a case-by-case basis to understand what a
hub
must do to accomdate.<SPAN class=394590015-25102004><FONT
face=Arial
color=#0000ff size=2> </FONT></SPAN></P>
<P><SPAN
class=394590015-25102004></SPAN> </P>
<P><SPAN class=394590015-25102004><FONT face=Arial
color=#0000ff
size=2>Patrick</FONT></SPAN><!-- **end egp html banner**
--></P></BLOCKQUOTE></BLOCKQUOTE>
<br>
<!-- **begin egp html banner** -->
<table border=0 cellspacing=0 cellpadding=2>
<tr bgcolor=#FFFFCC>
<td align=center><font size="-1"
color=#003399><b>Yahoo! Groups
Sponsor</b></font></td>
</tr>
<tr bgcolor=#FFFFFF>
<td align=center width=470><table border=0 cellpadding=0
cellspacing=0> <tr> <td align=center><font face=arial
size=-2>ADVERTISEMENT</font><br><a href="http://us.ard.yahoo.com/SIG=129ngsl1h/M=294855.5468653.6549235.3001176/D=groups/S=1705007709:HM/EXP=1098803017/A=2376776/R=0/SIG=11ldm1jvc/*http://promotions.yahoo.com/ydomains2004/index.html";
target="_blank"><img src="http://us.a1.yimg.com/us.yimg.com/a/ya/yahoo_domain/lrec_scuba_082004.jpg";
alt="click here" width="300" height="250"
border="0"></a></td></tr></table>
</td>
</tr>
<tr><td><img alt="" width=1 height=1 src="http://us.adserver.yahoo.com/l?M=294855.5468653.6549235.3001176/D=groups/S=:HM/A=2376776/rand=990116276";></td></tr>
</table>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<tt><hr width="500">
<b>Yahoo! Groups Links</b><br>
<ul>
<li>To visit your group on the web, go to:<br><a
href="http://groups.yahoo.com/group/xAP_developer/";>http://groups.yahoo.com/group/xAP_developer/</a><br>
<li>To unsubscribe from this group, send an email to:<br><a
href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>xAP_developer-unsubscribe@xxxxxxx</a><br>
<li>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/";>Yahoo!
Terms of Service</a>.
</ul>
</tt>
</br>
<!-- **end egp html banner** -->
</BODY></HTML>
------=_NextPart_000_0008_01C4BAAC.1B877560--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|
![http://us.a1.yimg.com/us.yimg.com/a/ya/yahoo_domain/lrec_scuba_082004.jpg"](http://us.a1.yimg.com/us.yimg.com/a/ya/yahoo_domain/lrec_scuba_082004.jpg"){kind=link}