What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
Go Back  Xtreme Visual Basic Talk > > > What could be the reason for the following socket behaviour


Reply
 
Thread Tools Display Modes
  #1  
Old 08-26-2010, 04:37 PM
CrashPilot CrashPilot is offline
Regular
 
Join Date: Jun 2009
Location: Netherlands
Posts: 73
Default What could be the reason for the following socket behaviour


I have created a Client that can send and receive data via TCP sockets.
The objects stored on the serverside are the *exact* same object used for the client. They use the same send and receive protocols.

Now, when i send a string from the server to the client , it does precisely what it should do. However when I send a string to the server.... I do receive the string as an equal length of NULL characters. I run the server and client locally.

Basicly what can influence the behaviour between two completely identical objects performing the exact same task? I wonder if there is some socketflag issue if the TCPlistener.accept function returns a completely different setup then the one I R used to.

(if it is of any interest, the send protocol is asynchronious)

Any input will be very apriciated,

Greetings,

Crash..
__________________
-- I divided by zero... and survived --
Reply With Quote
  #2  
Old 08-27-2010, 01:03 AM
CrashPilot CrashPilot is offline
Regular
 
Join Date: Jun 2009
Location: Netherlands
Posts: 73
Default

Ok I was wrong, it didn't have anything to do with the socket itself but with the memorystream that I use to receive chopped up files. When I read out this stream, the stream converts every character to NULL. It is still strange that one instance of an object does this, and the other doesn't......
__________________
-- I divided by zero... and survived --
Reply With Quote
  #3  
Old 08-27-2010, 08:44 AM
AtmaWeapon's Avatar
AtmaWeaponWhat could be the reason for the following socket behaviour AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

I'm confused, is there still a question? I see no reason why a memory stream would have this behavior. Perhaps there's something wrong with the code that encodes/decodes the strings?
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #4  
Old 09-06-2010, 03:03 AM
CrashPilot CrashPilot is offline
Regular
 
Join Date: Jun 2009
Location: Netherlands
Posts: 73
Default

The question solved itself basicly. The problem was still that the data got nullified when read at the client. Unfortunatly I made a small (BIG) mistake when coupling the .dll to the two seperate projects.

My server project had the entire project included while my client side only had a reference set to that .dll. I knew that just setting a reference to a .dll file may not automatically update that .dll as it is copied into the base folder but I noticed this error too late.

At the end I had two versions of these files, one was correct and running on the server, the other wasn't and ran on the client. It contained an error while writing to the buffer which made the data go poof.

Sorry for the late reaction on my own thread, I was away for a week for my work and didn't have the time to update it.

Cheers,

Crash
__________________
-- I divided by zero... and survived --
Reply With Quote
Reply

Tags
dataloss, directional, socket


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
 
What could be the reason for the following socket behaviour
What could be the reason for the following socket behaviour
 
-->