kalebdark / lidgren-network-gen3

Automatically exported from code.google.com/p/lidgren-network-gen3

KalebDark

Jekyll & Hide

lidgren-network-gen3's Issues

NetIncommingMessage.ReadByte hiding

The class NetIncommingMessage has method "byte ReadByte()" while 
System.IO.Stream has method "int ReadByte()", therefore ReadByte method is 
hidden.

Solution:
- NetIncommingMessage must override Stream.ReadByte instead of current method 
ReadByte.
- Optional add additional method (e.g. ReadAByte) which returns byte and not 
int.

Original issue reported on code.google.com by [email protected] on 25 Jul 2010 at 10:44

CS0162 Unreachable code detected

Compiler isn't happy in break after throw:
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetConnection.cs#641

Original issue reported on code.google.com by [email protected] on 9 Aug 2010 at 8:59

Missing Source Files

NetOutgoingMessage.Stream.cs and NetIncomingMessage.Stream.cs are missing in 
the repository!

Original issue reported on code.google.com by [email protected] on 14 Jul 2010 at 5:40

NetClient.SendMessage has no return value

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetClient.cs#87

One of NetClient.SendMessage overloads doesn't return any value, there it is 
impossible to check if sending failed.

Original issue reported on code.google.com by [email protected] on 5 Aug 2010 at 1:47

First Message using new delivery/channel not sent

During our Gen3 upgrade testing we noticed that sometimes messages get 
"swallowed" although the NetDelivery/Channel where set  (unlike in issue #9).

Further investigating lead us to conclusion that after a client connects and 
the server uses any delivery/channel combination for sending messages the very 
first message sent on a new channel/delivery gets swallowed.

We also have a bug open on the client side where the very first "player move" 
message gets ignored but all other mouse clicks cause the player to move as 
expected. The "move request" message uses as well a new delivery/channel as 
opposed to initial handshake,character retrieval, zone sync etc.

Sorry, I actually never tried to reproduce that in a small controlled 
environment as my time is very limited. But since we never suspected that 
Lidgren could be the cause we started bloating the source with logs all over 
the place. Just before a message gets send we have:
wm.Sender.SendMessage (sendBuffer, wm.DeliveryMethod, wm.DeliveryChannel);
Titanium.Borg.Shared.PlayerAction pa = 
(Titanium.Borg.Shared.PlayerAction)wm.Code;
log.InfoFormat("Turn {0}: Sent ZoneMessage ({1})@{2} -> delivery: {3}-{4}", 
wm.TurnNumber, pa, wm.Sender.RemoteEndpoint, wm.DeliveryMethod, 
wm.DeliveryChannel);

The Sender member is of type NetConnection. The remote endpoint is OK as well 
as the Status. I can confirm that all expected messages really get to that 
point.

On the receiving side we have:
receivedMsg = client.ReadMessage();
switch (receivedMsg.MessageType)
{ 
case NetIncomingMessageType.Data:
#if DEBUG
 Console.WriteLine("Data arrived bytes: " + receivedMsg.LengthBytes.ToString());
#endif


Finally, in the case the where the NetDeliveryMethod/Channel has changed the 
very first message reaches SendMessage but on the receiving side no 
NetIncomingMessage ever arrives (at least not with the 
NetIncomingMessageType.Data)!
In addition if we change all messages to use the same DeliveryMethod/Channel 
everything works as expected. I didnt check all possible combination's of 
DeliveryMethod's/channels so I cant point you in the right direction.

Original issue reported on code.google.com by [email protected] on 4 Jul 2010 at 8:46

Releasing resources

After you send a lot of messages and disconnects a connection, the memory is 
not totally cleared.

It is a good idea to add explicit Clear to the messages queues and other 
collections.

Original issue reported on code.google.com by [email protected] on 21 Sep 2010 at 5:36

NetIncommingMessage.Position in bits

It is good to add PositionInBytes property or perhaps Position returns bytes 
and add PositionInBits.

Original issue reported on code.google.com by [email protected] on 8 Sep 2010 at 7:53

Incorrect NetIncommingMessage.Seek

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetIncomingMessage.Stream.cs#40

You always reach throw.

Instead of break, use return Position; .
Or you can combine this together
 case SeekOrigin.Begin:   return Position  = offset * 8;
 case SeekOrigin.Current: return Position += offset * 8;
 case SeekOrigin.End:     return Position = (LengthBytes - offset) * 8;

Original issue reported on code.google.com by [email protected] on 17 Aug 2010 at 9:41

Incorrect documentation

For NetPeerConfiguration.ThrottleBytesPerSecond it is written:
Gets or sets the number of allowed bytes to be sent per second per connection; 
0 means unlimited

If you look at the source: 
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetPeerConfiguration.cs#348, you notice that thottleBytesPerSecond cannot be 
lower than MTU.

Original issue reported on code.google.com by [email protected] on 19 Aug 2010 at 6:56

Some optimization

You can use RemoveRange in NetPeer.ReduceStoragePool instead of RemoveAt(0):

int i = 0;
for( ; i < m_storagePool.Count && m_storedBytes > reduceTo; ++i)
 m_storedBytes -= m_storagePool[i].Length;

m_storagePool.RemoveRange(0, i);

Original issue reported on code.google.com by [email protected] on 21 Sep 2010 at 1:54

NetPeer.ToString() bug

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetPeer.cs#422
If m_socket is null?

Original issue reported on code.google.com by [email protected] on 7 Aug 2010 at 1:17

Lidgren.Network.NetConstants.NetChannelsPerDeliveryMethod should be public

There is no any public constant which tells how much channels you can use.
You can just call NetClient.SendMessage and get exception if channel is invalid.

The NetChannelsPerDeliveryMethod constant should be declared public somewhere.

Original issue reported on code.google.com by [email protected] on 12 Jul 2010 at 3:21

Array.Copy instead of for

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetBitWriter.cs#75
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetBitWriter.cs#149

Here goes
for (int i = 0; i < numberOfBytes; i++)
  destination[destinationByteOffset++] = fromBuffer[readPtr++];

You can use Array.Copy instead:

Array.Copy(fromBuffer, readPtr, destination, destinationByteOffset, 
numberOfBytes);

Original issue reported on code.google.com by [email protected] on 21 Jul 2010 at 3:28

Large messages can not be sent.

What steps will reproduce the problem?
1. Attempting to send a large string (90kb+ works at least)

What is the expected output? What do you see instead?
Other client should receive the message, but never gets it.

What version of the product are you using? On what operating system?
r48, Windows 7 x64

Please provide any additional information below.
This only worked sometimes before r48, but now it never does.

Original issue reported on code.google.com by [email protected] on 17 Jun 2010 at 10:53

NetUtility.Resolve(string ipOrHost)

What is the reason to check regular expression when you call IPAddress.TryParse 
in any case ?

P.S.
For null string you can throw ArgumentNullException.

Original issue reported on code.google.com by [email protected] on 6 Sep 2010 at 12:11

"KeepAliveDelay" and "PingFrequency" inconsistency

I'll illustrate this inconsistency by code.

// --- cut here ---
var config = new NetPeerConfiguration("SomeId")
    {
        PingFrequency = 6.0f, // same as default value
        KeepAliveDelay = 4.0f, // same as default value
    };
var Client = new NetClient(config);
Client.Start();
// --- cut here ---

I expect that code will compile and run because KeepAliveDelay is shorter than 
PingFrequency (as in xml documentation "Gets or sets the number of seconds of 
inactivity before sending an extra ping packet as keepalive. This should be 
shorter than ping interval").
Instead I get exception: "Setting KeepAliveDelay to lower than ping frequency 
doesn't make sense!"

I'm using code from "lidgren-network-gen3-2010-06-22.zip" archive.

Original issue reported on code.google.com by [email protected] on 24 Jun 2010 at 9:41

ReliableOrdered not working all the time

Using exclusively ReliableOrdered at a single sequence channel does not 
have the expected result of all messages being received in the order they 
were sent;

with two clients connected, and some messages sent to individual clients 
and some to both, the order of some of the messages received by the second 
client is jumbled even in a localhost setting.

Original issue reported on code.google.com by [email protected] on 17 May 2010 at 12:28

BUG !!! static NetIncomingMessage() maps to Int32 ReadByte() in s_readMethods

What steps will reproduce the problem?
1.  Breakpoint in on s_readMethods[it] = mi;
2.  Notice that Byte ReadByte values gets over written with Int32 ReadByte


What is the expected output? What do you see instead?

When using om.WriteAllFields in client   and om.ReadAllFields in server
an error occurs as above when serializing class with byte type properties
because it tries to assign a Int32 ReadByte method which is incompatible.

I tried stopping this happening by ensuring Byte ReadByte() reader is used 
instead by stopping previously allocated keys from being over written to the 
dictionary structure but when i start the server it shows errors with a key not 
found exception.


What version of the product are you using? On what operating system?
Latest version 2010-10-14 and previous version.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 15 Oct 2010 at 10:30

missing msserver

the msserver project referenced by the master server sample is missing from
the repository

Original issue reported on code.google.com by [email protected] on 12 May 2010 at 5:02

[deleted issue]

[deleted issue]

NetQueue.TryDequeue

Change it from 'public T TryDequeue()' to 'public bool TryDequeue(out T value)'

It conforms to ConcurrentQueue.TryDequeue method allowing easier migration if 
one needs.


Also this makes code cleaner with simpler check.

E.g.
NetSending uncSend;
while ((uncSend = m_unsentUnconnectedMessage.TryDequeue()) != null)
==>

NetSending uncSend;
while (m_unsentUnconnectedMessage.TryDequeue(out uncSend))

Original issue reported on code.google.com by [email protected] on 5 Sep 2010 at 9:25

Limited cryptography options

Currently in lidgren, it's only hardcoded XTEA that is allowed as an option if 
you wish to encrypt messages, at least without doing it yourself.

I made a patch that fixes this issue by changing it so that it is a public 
interface, and also added some more ciphers to choose from (AES, DES, 
TripleDES, RC2, and of course XTEA). It also updates the unit tests so that in 
case you add more later, so long as they implement 
Lidgren.Network.Encryption.iNetEncryption, they will automatically be tested 
(assuming they include a constructor that contains a single string).

Note that I did make this in VS2010, so I did have to manually edit some of the 
parts for the csproj patch. It should not be much of an issue though, I just 
wanted to note that in case of issues arising.

Original issue reported on code.google.com by [email protected] on 6 Aug 2010 at 4:05

Attachments:

• Lidgren.patch

Lidgren crashes Unity3D

What steps will reproduce the problem?
1. use client.Start() in Unity3D

What is the expected output? What do you see instead?
It should do what it is supposed to do, instead Unity3D and the game crash

What version of the product are you using? On what operating system?
Gen 3, June 1st. Windows 7

Please provide any additional information below.
Everything works fine with XNA, problem is in Unity3D, I'm pretty sure Unity 
wasn't in your list of "intended uses" for Lidgren Network to begin with though.

Original issue reported on code.google.com by [email protected] on 18 Jun 2010 at 2:28

NetConnection.SendConnectReponse and m_remoteUniqueIdentifier

Is there any reason why NetConnection.SendConnectReponse doesn't use 
m_remoteUniqueIdentifier in the response for a better handshake check ?

internal void SendConnectResponse()
{
  ...
  reply.Write(m_remoteUniqueIdentifier);
  ..
}

And then check in the NetPeer.Internal when ConnectResponse comes not only for 
sender but with the uniqueId too.

Also NetConnection.m_remoteUniqueIdentifier is initialized only in server side 
when NetMessageLibraryType.Connect message is received but not for client side 
in Connect method.

NetPeer.Connect method can initialize NetConnection:
public virtual NetConnection Connect(...)
{
 ...
 conn.m_remoteUniqueIdentifier = m_uniqueIdentifier;
 m_connections.Add(conn);
 ...
}


Otherwise I don't see the need of unique identifier in the connection.

Original issue reported on code.google.com by [email protected] on 17 Aug 2010 at 1:42

the sample imageclient throw exception

What steps will reproduce the problem?
1.run imageserver
2.run imageclient
3.click spawnimagegetter

What is the expected output? What do you see instead?
no exception throwed

What version of the product are you using? On what operating system?
2010-08-27

Please provide any additional information below.
the running thread not the networkthread, but the user thread, 
this caused by the new add in netconnection.cs line 723. 

Original issue reported on code.google.com by [email protected] on 30 Aug 2010 at 7:54

Readonly fields

You can set many fields as readonly, such as:

NetConnection.m_fragmentGroups
NetConnection.m_statistics
NetConnection.m_unsentMessages
NetPeer.m_senderRemote
NetPeer.m_listenPort

The simplest solution is to put readonly on all fields and then remove on those 
where it is impossible.

Original issue reported on code.google.com by [email protected] on 11 Aug 2010 at 4:06

NetQueue bugs

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetQueue.cs#176
if m_items[ptr] is null?

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetQueue.cs#190
and m_size = 0

Original issue reported on code.google.com by [email protected] on 2 Sep 2010 at 6:25

Exception thrown from thread

Look at this line 
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetPeer.cs#144 :

m_networkThread = new Thread(new ThreadStart(Run));

And then closely to Run method:
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetPeer.Internal.cs#73

In this method when you cannot bind socket or on any other problem exception is 
thrown outside the thread !!

Here: 
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetPeer.Internal.cs#149


Now, what happens, noone can handle this exception and program aborts!

It is better to write a log instead.
Status property can give the information whether Run is called successfully.


Proposed solution:

catch (SocketException ex)
{
 if (sex.SocketErrorCode == SocketError.AddresssAlreadyInUse)
   LogError(...)
 else
  LogError(sex.Message);
 return;
}
catch (Exception ex)
{
 LogError(...)
 return;
}

Original issue reported on code.google.com by [email protected] on 10 Aug 2010 at 10:28

NetConnection - NetPeer design

If you have NetConnection, you can't create a message since there is no method 
NetConnection.CreateMessage.

So you go to the NetConnection.Owner.CreateMessage method.

The problem with the Owner property that it gives you a full NetPeer access.
It could be nicer to introduce INetPeer interface which gives you only a needed 
methods like CreateMessage and Recycle.

Original issue reported on code.google.com by [email protected] on 13 Sep 2010 at 11:01

Large amount of data retransmission

What steps will reproduce the problem?
1.run imageserver
2.run imageclient
3.click imageget

What is the expected output? What do you see instead?
not resend data in local environment.

What version of the product are you using? On what operating system?
all version

Please provide any additional information below.
set resend time in 
EnqueueSendMessage   netconnection.cs line 676

i think this is not the right time.
so i delay to set resend time to before send it in
Heartbeat  netconnection.cs line 235

no resend in local environment now.

Original issue reported on code.google.com by [email protected] on 3 Sep 2010 at 3:17

loss packet no accept

What steps will reproduce the problem?
1.add simulation loss code in server
2.run server
3.run client

What is the expected output? What do you see instead?
server resend data to client, and client can process it.

What version of the product are you using? On what operating system?
all version

Please provide any additional information below.
if client receive a packet not the ordered (lost one packet), and then it 
withhold it in a queue, this in ok. but when client receive the lost packet, 
client just add the lost packet to the receive buffer, but the withhold 
messages will be lost. so the client will never finished. 

Original issue reported on code.google.com by [email protected] on 3 Sep 2010 at 3:12

NetOutgoingMessage.Write(string source) bug

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetOutgoingMessage.Write.cs#521

Original issue reported on code.google.com by [email protected] on 2 Aug 2010 at 2:40

AssemblyVersion

It doesn't seem like you are planning to use the AssemblyVersion attribute in 
the Properties\AssemblyInfo.cs.

I'd like to suggest that you enter something like

[assembly: AssemblyVersion("2010.06.28.0")]
[assembly: AssemblyFileVersion( "2010.06.28.0" )]

to help developers trace the assembly back to a specific version.

The attached image shows the assembly file version with (right) and without 
(left) the changed versioning information.

Original issue reported on code.google.com by [email protected] on 11 Jul 2010 at 10:12

Attachments:

• ProductVersionExample.png

Public methods

Every public method must check arguments for null and throw 
ArgumentNullException instead of CLR throwing NullReferenceException.

Original issue reported on code.google.com by [email protected] on 22 Jul 2010 at 12:49

No Abort Thread in shutdown method for netpeer class

Ive noticed that when I shutdown my project i these messages

A first chance exception of type 'System.Threading.ThreadAbortException' 
occurred in DreamForgeCore.exe
An exception of type 'System.Threading.ThreadAbortException' occurred in 
DreamForgeCore.exe but was not handled in user code

I stepped through code and noticed there is no m_networkthread.abort() in 
the shutdown method not sure if this is whats caussing that error gonna 
test it now with a patch of my own and post results.

Original issue reported on code.google.com by [email protected] on 19 May 2010 at 11:20

Trouble with senging files across LAN

I'm writing client\server app for sending files using your library. When I 
upload one file at time everything is good (most of time). But when I try to 
upload two or more files... here comes trouble. :)

I've included copy of my test project source files and binaries in attachment.

I understand that bug could be in my code instead of yours. If it's that case I 
apologize.

If you have any other questions regarding this issue, please ask. I just do not 
know what information might be useful for you for pinpointing that problem.

Send/Receive buffers is set to 1048576 in both client and server.


Files are saved in system temporary directory (Path.GetTempPath()). After 
processing FinalizeUpload corresponding file is moved to the final location 
(appPath\Uploads).
BeginUpload->UploadChunk (repeat N times)->FinalizeUpload



What steps will reproduce the problem?
0. Compile project in MSVS2010. Or run binaries I've provided in attachment ( 
.net 4.0 is required)
1. Prepare two 30-50Mb files (archives, music, video, whatever. that does not 
matter)
3. Run TestServer.exe
4. Run two instances of TestClient.exe.
5. In "Client1" click "UploadFile" button and select first file.
6. In "Client2" click "UploadFile" button and select second file.
7. Start upload process by cicking Open in dialog boxes.

--- another way
1. Prepare two 50+ Mb files.
2. Run TestServer.exe
3. Run one instance of TestClient.exe
5. Click "UploadFile" button, select file, hit "open" in dialog box. Wait until 
file is uploaded. Close client.
6. Run again TestClient.exe.
7. Try to upload another file.

Sometimes I need to repeat steps, because bugs won't show themselves.


What is the expected output? What do you see instead?
--> I expect that files will be copied to destination (appDir\Uploads). But 
instead I get weird exceptions.


What version of the product are you using? On what operating system?
--> I've included source code of your library with my test project.
--> Windows 7 x64. I've tested my project on Windows XP sp3. Same results.

----- additional information -------

So far I've got three different exceptions:

------- first exception ---------
Source: Lidgren.Network
Stack Trace:
at Lidgren.Network.NetException.Assert(Boolean isOk, String message)
    in \Lidgren.Network\NetException.cs:line 58
at Lidgren.Network.NetIncomingMessage.ReadBytes(Int32 numberOfBytes)
    in \Lidgren.Network\NetIncomingMessage.Read.cs:line 113
at TestServer.Program.ProcessIncomingDataMessage(NetIncomingMessage msg)
    in \TestServer\MessageProcessing.cs:line 24
Target Site: Void Assert(Boolean, System.String)
>Lidgren.Network:Trying to read past the buffer size -
likely caused by mismatching Write/Reads, different size or order.

------- second exception ---------
Source: mscorlib
Stack Trace:
at System.Text.Encoding.ThrowCharsOverflow()
at System.Text.Encoding.ThrowCharsOverflow(DecoderNLS decoder, Boolean 
nothingDecoded)
at System.Text.UTF8Encoding.GetChars(Byte* bytes, Int32 byteCount, Char* chars, 
Int32 charCount, DecoderNLS baseDecoder)
at System.String.CreateStringFromEncoding(Byte* bytes, Int32 byteLength, 
Encoding encoding)
at System.Text.UTF8Encoding.GetString(Byte[] bytes, Int32 index, Int32 count)
at Lidgren.Network.NetIncomingMessage.ReadString()
    in \Lidgren.Network\NetIncomingMessage.Read.cs:line 446
at TestServer.Program.ProcessIncomingDataMessage(NetIncomingMessage msg)
    in \TestServer\MessageProcessing.cs:line 18
Target Site: Void ThrowCharsOverflow()

>mscorlib:The output char buffer is too small to contain the decoded 
characters, encoding 'Unicode (UTF-8)' fallback 
'System.Text.DecoderReplacementFallback'.
Parameter name: chars

------- third exception ---------
Source: mscorlib
Stack Trace:
at System.Buffer.BlockCopy(Array src, Int32 srcOffset, Array dst, Int32 
dstOffset, Int32 count)
at Lidgren.Network.NetBitWriter.ReadBytes(Byte[] fromBuffer, Int32 
numberOfBytes, Int32 readBitOffset, Byte[] destination, Int32 
destinationByteOffset)
    in \Lidgren.Network\NetBitWriter.cs:line 75
at Lidgren.Network.NetIncomingMessage.ReadBytes(Int32 numberOfBytes)
    in \Lidgren.Network\NetIncomingMessage.Read.cs:line 116
at TestServer.Program.ProcessIncomingDataMessage(NetIncomingMessage msg)
    in \TestServer\MessageProcessing.cs:line 24
Target Site: Void BlockCopy(System.Array, Int32, System.Array, Int32, Int32)

>mscorlib:Offset and length were out of bounds for the array or count is 
greater than the number of elements from index to the end of the source 
collection.

Packet parsing error: Offset and length were out of bounds for the array or 
count is greater than the number of elements from index to the end of the 
source collection.

Original issue reported on code.google.com by [email protected] on 28 Oct 2010 at 3:50

Attachments:

• FileSendTestProject.zip

NetUtility.ToHexString(byte[] data) improvement

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetUtility.cs#149
sb.Append(b.ToString("X2"));

=)

Original issue reported on code.google.com by [email protected] on 7 Aug 2010 at 2:05

NetSha thread safety

NetSha.Hash method isn't thread safe. (I have got the CryptographicException)
Although it is protected in NetPeer.Internal with lock , two NetPeers can call 
this method simultaneously.

Moreover according to MSDN ( 
http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha1.aspx  
)
"Any public static (Shared in Visual Basic) members of this type are thread 
safe. Any instance members are not guaranteed to be thread safe."

ComputeHash is an instance method, therefore not thread safe.

Solution:
Since this method is needed primarily in NetPeer.InitializeNetwork which is 
called only once per NetPeer, this method can be surrounded with simple lock.

Original issue reported on code.google.com by [email protected] on 26 Sep 2010 at 11:01

NetIncomingMessage.Clone

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetIncomingMessage.cs#141
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetIncomingMessage.cs#149
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetIncomingMessage.cs#150

;)

Original issue reported on code.google.com by [email protected] on 7 Aug 2010 at 1:39

internal members to public properties

Instead of internal members it is better to use private fields and public 
properties.
In fact in most cases there are public properties but they are not used.

Only in case when the member must be not exposed to the user the internal 
property could be used.

Original issue reported on code.google.com by [email protected] on 17 Aug 2010 at 10:51

NetConnection doesn't update always m_visibleStatus

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetConnection.Handshake.cs#54

According to this line, m_visibleStatus is updated only if StatusChanged 
message is disabled and not always.

m_visibleStatus must be updated regardless if StatusChanged is enabled or not.

This issue prevents the following code to be correct:

var c = client.Connect(ip);

for (var i = 0; i < 10000; i += 1000)
  if (c.Status == NetConnectionStatus.Connected)
    return true;
  else // Wait
    Thread.Sleep(1000);

return false;

Original issue reported on code.google.com by [email protected] on 26 Jul 2010 at 9:57

Recycling outgoing message

What steps will reproduce the problem?
1. Sending many messages on the connection consumes a lot of memory.
2. Outgoing messages are not recycled.

What is the expected output? What do you see instead?
Memory should stay at some point and not grow inefficiently.

After some profiling I have got to NetConnection.HandleIncommingAcks method and 
I have found that outgoing messages are not recycled.

// TODO: recycle send
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetConnection.Reliability.cs#190

This means that messages are recycled only when the connection is disconnected. 
It is not good for long living connection or for huge traffic connection.

Please add recycling for outgoing messages.

Thanx !

Original issue reported on code.google.com by [email protected] on 5 Sep 2010 at 9:17

NetConnectionStatistics.ResentMessages property

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetConnectionStatistics.cs#39

Although the variable is introduced and used in ToString method there is no 
property to read it.

Please add ResentMessages property.

Original issue reported on code.google.com by [email protected] on 14 Sep 2010 at 8:44

[deleted issue]

[deleted issue]

Many Clients make server unstable!

Many Clients(>100) will make server unstable,some of clients will lost 
connection,and the server has high CPU Usage,almost 100%.

Original issue reported on code.google.com by [email protected] on 26 Sep 2010 at 1:25

NamespaceDoc.cs missing

What steps will reproduce the problem?
1. Download the latest SVN
2. Try to compile with visual studio's

What is the expected output? What do you see instead?
The DLL file

What version of the product are you using? On what operating system?
latest

Please provide any additional information below.
The NamespaceDoc.cs is missing from the SVN so you can't compile lidgren.

Original issue reported on code.google.com by [email protected] on 22 Oct 2010 at 12:40

Optional thread name

Given a number of NetPeers it could be better to distinguish between them.

Patch:
http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetPeerConfiguration.cs

internal string m_threadName;
public string ThreadName
{
  get { return m_threadName; }
  set
  {
    if (m_isLocked)
        throw new NetException(c_isLockedMessage);
    m_threadName = value;
  }
}

http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Networ
k/NetPeer.cs#147

const string LidgrenThreadName = "Lidgren network thread";
if (m_configuration.m_threadName != null)
  m_networkThread.Name = LidgrenThreadName + "(" + m_configuration.m_threadName + ")";
else 
 m_networkThread.Name = LidgrenThreadName;


Optional:
This can be added to [DebuggerDisplay] too.

Original issue reported on code.google.com by [email protected] on 12 Aug 2010 at 5:15

Supported Dictionary<Object,Object> in Write/Read Overloaded Method

Introducing this 17 October
Will send code update
Hope its useful

Original issue reported on code.google.com by [email protected] on 17 Oct 2010 at 9:47

Connect/Disconnect per channel.

Current NetIncommingMessageType.StatusChanged goes for overall status.
It would be nice to add additional types specific for channels:
 NetConnectionStatus.ChannelConnected
 NetConnectionStatus.ChannelDisconnected

Additional methods could be introduced:
 NetClient.ConnectChannel - called automatically by NetClient.SendMessage
 NetClient.DisconnectChannel - tells NetServer about disconnecting channel.


Current way is passing this via NetIncommingMessageType.Data and parsing.

Thank you.

Original issue reported on code.google.com by [email protected] on 13 Jul 2010 at 10:39

NetDeliveryMethod should be explicitly checked

After porting the Borg Server framework to use Gen3 instead he old lib some 
messages where randomly not sent. It turned out we forgot to set explicitly the 
NetDeliveryMethod on some places. Therefore our network pump sometimes used 0 
or other garbage values.

Rather than silently swallowing error condition (in release build without 
verbose on) and not sending the message an explicit check for valid 
NetDeliveryMethod values should be made resulting with an Exception on garbage.

Original issue reported on code.google.com by [email protected] on 30 Jun 2010 at 9:41