Re: reading network data
- From: "Alf P. Steinbach" <alfps@xxxxxxxx>
- Date: Sun, 25 Nov 2007 11:46:08 +0100
* Ender:
(1) Do you know that you are looking in the right place or might that
be in question too? It helps a lot if you are sure of all the
encapsulating header formats -- including the inner-most one where the
data is actually being represented.
No, I'm looking in the right place, right machine, right port. I'm using wireshark to try to confirm it. It shows the packet's src, dest, port, etc... info. But even in wireshark, I see the same info that's in my receive buffer. So that tells me it's looking in the right place as well.
(2) What kind of number is being sent? You say coordinates, but of
what? It helps to know what the data is when trying to see how it is
being represented.
And I know what the data should look like. It's just some colon delimited floats, one after another, 3 floats long. e.g. "2.032:6.33:9.21"
The data is not encrypted.
(4) How sure of that are you? One way to test is to take a chunk of
it and try to compress it with an general-purpose data compressor like
gzip. Of course, there is no need to do that if you can see
patterns.
Positive, it's not encrypted.
So here's my question, if I send unencrypted numbers across the wire, that's exactly what I should see in my read() buffer on the other side, correct?
Why don't you post some code, of the program that generates the packets.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
.
- References:
- Re: reading network data
- From: Ben Bacarisse
- Re: reading network data
- Prev by Date: Re: reading network data
- Next by Date: Binary search tree
- Previous by thread: Re: reading network data
- Next by thread: Re: reading network data
- Index(es):
Relevant Pages
|