IRC Logs

Network: freenode Channel: #csharp

	Enter your search terms Submit search form
	Web www.irclog.org

[19:47]<hallnzvan>can someone explain why the sent TCP string is received as 1 package ? http://authors.aspalliance.com/aylar/ViewPasteCode.aspx?PasteCodeID=5983
[19:48]<hallnzvan>the result is [1|10][1|10]
[19:51]<rrrdjdtxyrr>Hoppertje: Description in VS says it's reserved for future use. Would this mean that it hasn't been implemented yet?
[19:51]<rrrdjdtxyrr>or am I just not understanding it?
[19:52]<hallnzvan>huh?
[19:52]<hallnzvan>i think you are misunderstanding :)
[19:53]<rrrdjdtxyrr>from MSDN: The Flush method implements the Stream.Flush method; however, because NetworkStream is not buffered, it has no affect on network streams. Calling the Flush method does not throw an exception.
[19:53]<kjr>ah hah, found .NET3 RC
[19:53]<kjr>http://www.microsoft.com/downloads/details.aspx?FamilyId=19E21845-F5E3-4387-95FF-66788825C1AF&displaylang=en
[19:54]<hallnzvan>ns.Write(Encoding.ASCII.GetBytes(TcpRawString), 0, TcpRawString.Length); I was assuming here that Length was determining the end of package
[19:54]<hallnzvan>recv = ClientStream.Read(DataBuffer, 0, DataBuffer.Length); and by reading it, it would only read the length that was sent before reading the next one
[19:54]<rrrdjdtxyrr>meh... good point... I may have been looking at the wrong bit of it, I was just assuming the flush had no effect...
[19:55]<hallnzvan>:)
[19:55]<rrrdjdtxyrr>Could it depend on how quickly the server is reading the data?
[19:55]<rrrdjdtxyrr>i.e. introduce a delay and see if it comes as 2 packets?
[19:55]<hallnzvan>i have no idea? I am really new to this, and i can't get the answer from my bookie
[19:56]<rrrdjdtxyrr>I don't really know... I started programming network stuff in .NET about 3 hours ago.
[19:56]<hallnzvan>hmmm hehe, then i am more advanced :P
[19:57]<hallnzvan>Kog, are you any good in TCP ?
[19:57]<kjr>I've been known to use TCP/IP every once in a great while
[19:57]<rrrdjdtxyrr>more advanced or just been using it longer?
[19:57]<hallnzvan>RandomThing, both :P
[19:57]<rrrdjdtxyrr>more advanced is probably right.
[19:57]<rrrdjdtxyrr>:)
[19:58]<hallnzvan>Kog: in ns.Write(Encoding.ASCII.GetBytes(TcpRawString), 0, TcpRawString.Length); is length not used here as received_end_of_package ?
[19:58]<hallnzvan>even in a stream
[19:59]<kjr>it's the number of bytes to write out to the stream
[19:59]<kjr>SpikeLite msdn2 networkstream
[19:59]<slycnlyvn>Kog, NetworkStream Class (System.Net.Sockets): http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx
[19:59]<hallnzvan>which is set on 1024, but, .length calculates the actual bytes, right?
[19:59]<kjr>http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.write.aspx
[19:59]<kjr>buffer, offset, size
[20:00]<kjr>size is defined as "The number of bytes to write to the NetworkStream."
[20:01]<hallnzvan>right, thats what i figured.... so in http://authors.aspalliance.com/aylar/ViewPasteCode.aspx?PasteCodeID=5983 why are 2 strings sent as 1
[20:01]<hallnzvan>or read as 1 by recv = ClientStream.Read(DataBuffer, 0, DataBuffer.Length);
[20:02]<hallnzvan>and MSDN is kinda useless to beginners
[20:03]<kjr>you should call .Length on the byte[], not the string
[20:03]<kjr>because of the encodings
[20:04]<rrrdjdtxyrr>just a quick point... Won't the stream buffer until it's read (at the server side) and therefore it'll read both at the same time when trying to receive?
[20:05]<vufvuzn>Hoppertje: it's a _stream_ - there's no definition of "strings" within that stream
[20:05]<vufvuzn>it's just one continuous flow of bytes
[20:05]<rrrdjdtxyrr>despite the fact it'll be gone from client side, the server buffer will just see it as one stream of data and therefore read the whole stream when it calls receive
[20:05]<hallnzvan>NetworkStream ClientStream = Server.GetStream(); so the length should be on ClientStream ?
[20:05]<kjr>depends on how the read is done
[20:05]<kjr>Hoppertje: streams don't have length
[20:06]<kjr>ok, so you create a byte[] on the Encoding.whatever.GetBytes
[20:06]<kjr>the size of the write should be the size of that byte[], not the number of chars in th e string
[20:06]<kjr>some alphabets use 3 or 4 bytes per character
[20:06]<hallnzvan>hmmm
[20:06]<kjr>dig?
[20:06]<hallnzvan>kinda
[20:07]<kjr>since you're using ASCII you'll only be off by half
[20:07]<rrrdjdtxyrr>with encoding.ascii it will be 1 byte per char tho, right?
[20:07]<kjr>2
[20:07]<rrrdjdtxyrr>really?
[20:07]<hallnzvan>i also thought 1
[20:07]<rrrdjdtxyrr>you sure about that?
[20:07]<hallnzvan>thats what my book says
[20:07]<kjr>no wait, 1 sorry
[20:07]<kjr>char is 2 by default
[20:07]<rrrdjdtxyrr>unicode would be 2 per char
[20:07]<kjr>no, unicode would be variable heh
[20:07]<kjr>it ends up doing chunking I think
[20:08]<hallnzvan>will read also read the length of the sent package ?
[20:08]<kjr>sup vulture
[20:08]<rrrdjdtxyrr>hmm... i thought it was 2, but I could easily be wrong on that. was sure ascii was 1 tho
[20:08]<rrrdjdtxyrr>read will read whatever's in the buffer up to a limit that's provided to it...
[20:08]<kjr>RandomThing: ASCII can be represented with 128 characters... it should be 8bit. However, default chars are 16
[20:09]<hallnzvan>I can't believe this
[20:09]<kjr>Hoppertje: the fastest, dirtiest hack you can do is delimit your app protocol w/ EOL ;)
[20:09]<kjr>then ReadLine
[20:10]<hallnzvan>i replaced TcpRawString.Length where TcpRawString = "[1|10]"; for 6 and it worked
[20:10]<hallnzvan>how confusing
[20:10]<kjr>not really
[20:10]<kjr>it was blocking
[20:10]<hallnzvan>but TcpRawString = "[1|10]" <-- thats 6 bytes
[20:10]<vufvuzn>that's 7 chars, how many bytes depends on the encoding
[20:10]<vufvuzn>s/7/6/
[20:10]<hallnzvan>man
[20:11]<kjr>vulture: he's using ASCIIEncoding
[20:11]<hallnzvan>how bugged is that
[20:11]<kjr>Hoppertje: not at all
[20:11]<vufvuzn>how what?
[20:11]<kjr>Hoppertje: if you'd listen to me and call Length on the byte[]
[20:11]<kjr>you'd do just fine
[20:11]<vufvuzn>character encoding isn't simple, nor is it something you can easily ignore..
[20:11]<vufvuzn>Kog: what's the issue?
[20:11]<kjr>vulture: his read was blocking and he couldn't figure out why
[20:11]<kjr>vulture: so I told him to call length on the byte[] and not the string
[20:12]<vufvuzn>Kog: which read?
[20:12]<kjr>vulture: you see the latest topic addition?
[20:12]<kjr>the read on his tcplistener
[20:12]<vufvuzn>his description doesn't seem to indicate that anything was blocking
[20:13]<vufvuzn>seemed to me he ended up reading two "writes" with one read, because he didn't understand the nature of a stream
[20:13]<hallnzvan>vulture: http://authors.aspalliance.com/aylar/ViewPasteCode.aspx?PasteCodeID=5983 if you're interested
[20:13]<kjr>oh, right
[20:13]<kjr>bbl
[20:13]<hallnzvan>vulture: i thought i understood that a stream - package was defined by the length given to the package
[20:14]<vufvuzn>Hoppertje: streams don't have packets
[20:14]<vufvuzn>packages, frames, segments, or anything like that

Back to #csharp
Or go to some related logs:
#gentoo
#azureus
#gentoo
#gentoo
#debian