使用 TCP 套接字解析 Windows Phone 7 上的 xml 内容
我正在开发 Windows Phone 7 的应用程序。
我有一个使用 C# silverlight 中的 tcp 套接字来解析 xml 流。我正在尝试使用 xmlreader 和内存流,但没有任何帮助。当内存流通过接收异步调用更新时,xmlreader 不会对该读取器产生影响。
请帮助我了解如何从套接字解析流式 xml。
我有一个 xmlReader,这样:
memoryStream= new MemoryStream();
_xmlreader = XmlReader.Create(memoryStream, xmlReaderSettings, context);
现在 memoryStream 更新为:
byte []buffer = "initialized with some xml bytes such as <node1> data </node1>"
因为该缓冲区由套接字 receiveasync 操作(即 xml)填充。 现在我需要更新我的数据。所以我这样做...
memoryStream = memoryStream.write(buffer,0,buffer.length);
现在,当我这样做时 _reader.read 失败了。我不明白为什么会这样。否则是否有 xmlpullparser (sax) 之类的东西,就像我们在 android 操作系统中用于 xml 解析一样,
while (_reader.Read())
{
switch (_reader.NodeType)
{
case XmlNodeType.Element:
{
node = new XElement(_reader.Name);
xmlBuildStack.Push(node);
}
break;
case XmlNodeType.EndElement:
.....
是否有任何其他方法可以解析来自 tcp 套接字流的 xml,因为我正在开发使用 xmpp xml 节的聊天应用程序。请帮我解决这个问题。
I am working on an application for windows phone 7.
I have a to parse xml stream using tcp sockets in c# silverlight. I am trying it using xmlreader and memory stream but it is of no help. When memory stream is updated by a receive async call, xmlreader has no impact of that reader.
Please help me on how to parse streaming xml from sockets.
I have a xmlReader such that:
memoryStream= new MemoryStream();
_xmlreader = XmlReader.Create(memoryStream, xmlReaderSettings, context);
now memoryStream is updated as:
byte []buffer = "initialized with some xml bytes such as <node1> data </node1>"
as this buffer is filled by socket receiveasync operation which is xml.
now i need to update the my data. so I do this...
memoryStream = memoryStream.write(buffer,0,buffer.length);
Now when i do this _reader.read fails. I don't why is this happening. otherwise is there is xmlpullparser (sax) like thing as we have in android os for xml parsing
while (_reader.Read())
{
switch (_reader.NodeType)
{
case XmlNodeType.Element:
{
node = new XElement(_reader.Name);
xmlBuildStack.Push(node);
}
break;
case XmlNodeType.EndElement:
.....
is there any other way possible to parse xml which comes from tcp socket stream as i am working on chat application which uses xmpp xml stanzas. please help me in solving this scenario.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不幸的是,XmlReader 对于 XMPP 来说几乎没用。在处理任何输入之前,它会缓冲到 4kB,无论您连接到它的流是什么。
即使作为第一次向自己证明这一点的黑客,您也不应该编写一个将每个入站节填充到 4kB 的流,而只能在节边界上填充。
为了解决这个问题,我将 James Clark 的 XP 解析器的部分移植到了 C#。如果 LGPL 适合您,您可以提取 xpnet 来自 jabber-net (我尚未更新以支持 WinPhone7) ,或发送如果你让整个库正常工作,我会打补丁。
XmlReader is nearly useless for XMPP, unfortunately. It buffers to 4kB before processing any input, regardless of the stream you hook up to it.
Even as a first hack to prove this to yourself, you shouldn't write a stream that pads every inbound stanza to 4kB, but ONLY on stanza boundaries.
To get around the problem, I ported the parts of James Clark's XP parser to C#. If LGPL works for you, you could pull xpnet out of jabber-net (which I haven't updated to support WinPhone7), or send me patches if you get the entire library working.
MemoryStream
无法按照您希望的方式工作。当XmlReader
读取到当前末尾(即消耗所有当前数据)时,它将报告已到达文件末尾。您真正需要的是在 TCP 套接字周围封装一个流。可能最简单的方法是使用 TcpClient< /a> 而不是原始套接字。
GetStream
方法将执行您想要的操作 - 提供一个流,您可以从中创建XmlReader
。另一种选择是创建一种满足您要求的流类型。也就是说,它让一个线程放入数据,另一个线程取出数据。但消费者不会报告文件结束,直到生产者说发生文件结束。
几个月前我写并发表了类似的东西。请参阅构建新型流。
老实说,不过......在这种情况下,
TcpClient
将是我的首选。MemoryStream
doesn't work the way you want it to. When theXmlReader
reads to the current end (i.e. consumes all of the current data), it's going to report that it's reached end of file.What you really need is to wrap a stream around the TCP socket. Probably the easiest thing to do would be to use a TcpClient rather than a raw socket. The
GetStream
method will do what you want--provide a stream from which you can create anXmlReader
.Another option is to create a type of stream that does what you're asking. That is, it lets one thread put data in and another take data out. But the consumer doesn't report end of file until the producer says end of file has occurred.
I wrote and published something like this a few months back. See Building a New Type of Stream.
Honestly, though ...
TcpClient
would be my preference in this case.