cypherkronis

i have a socket program running thanks to cerulean. it passes data back and forth between clients. when i print the data coming in to a client, it prints a series of 0's. but its a string. so i wanted to make it an int, i used int(data). unfortunately, this produces an invalid literal error. why wont it let me do this? they Are 0's in string form. i thought perhaps there was extra whitespace that was making the conversion from string to int mess up, so i used strip(). still no luck. what can be the problem?

sigh..i've found the problem. somehow when i send the data FROM my client, =what is recieved is inconsistent. i only noticed this when i slowed the output down to a delay of about 10000 ms. damn..

well, i checked everything. the data that the clients are sending sometimes comes a bit skewed back to the other client. theres an extra 0 or that really messes things up sometimes. i know its not my clients send data, cuz i checked it, its consistently good. i compared what client 1 was sending directly to what client 2 was recieving and it WAS different. damn...i'll guess i'll have to accept that these errors occasionally occur and use a try/except block or something

DaWei

I would suggest that you probably have an error in your code; particularly if you're using TCP/IP.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Cerulean

I assume you're using UDP? With UDP there is no way of telling what has ended up where, but it tends to be much faster.. If you are, I really do recommend you use TCP - you won't get much of a performace gain with UDP unless you really know what you're doing.
If you're using TCP, bear in mind the fact that sometimes packets may get grouped together, or you'll receive different bits at different times. With that said, I have found consistency to be excellent with all the client/server applications i've created.

cypherkronis

how do u mean, different bits at a time? i was expecting to get one full thing of data from one "send" command to arrive intact. is this not the case?

Cerulean

To be honest I was basing this on prior experience with a TCP client application which may have grouped packets together for the sake of efficiency (it was a game client). I'm not sure if Python does anything of the same.
If you're using TCP, show some code and let's see if we can get it to work.

Dameon

There's actually a flag to set on the socket to prevent this scheduling when working with a real time application like a game. According to some sources I have laying around you need to set the socket option "TCP_NODELAY".

From my TCP and socket experience, you absolutely cannot assume that the socket will give you the amount of data you requested. The parameter for max bytes to read or send is in many cases not how many you actually read or send. Check the return value. That tells you how many bytes were actually read or sent, and in the case of reading will give you 0 if the remote client closed the connection. In many cases the stream is chopped up into small segments. Even for file transfer, it's not just a straightaway send-fest with data going in one direction. Data goes back and forth. Something like packets on top of packets. The simplest way to do this is to in your sending code first write the length of the chunk you are sending, then in the receiving code read the length (don't assume it comes in with one recv call even though it is only a few bytes. It most likely will but do you really want your stream offset by a few bytes and get a bunch of garbage?) and then you can keep reading until you read that exact amount of bytes. The length can be a little nasty. Do a lot of sanity checking on the length before you start trying to read that many bytes. It could very well come in as 0 (which has caused me some nasty debugging sessions...reading with a max of 0 bytes doesn't work very well, let me tell you, but took me forever to track down) or an insanely large number that will keep you in the loop for eternity. An easy way to determine if you are getting garbage data is to, before the length, stick a little header. This is the oldest trick in the book as far...its used on just about every file format and protocol I've worked with. This includes HTTP (Capture some packets. Every chunk starts with HTTP) and the PE executable format used on windows (First two bytes are always "MZ"). This adds another few lines, but you can immediately tell if one of the clients isn't working properly. If the first few bytes of the message aren't what you expect, throw an error. Feel free to use your initials. Just my $0.02.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270