August 26th, 2003, 06:13 AM
we r using byte becoz of faster transfer of data, i don't know if we just send one int at a time , if that would make difference, if it does plz let me know.
Secondly i tried using ntohl in my C++ client side but it didn't worked. (i will try it again) but do i have use htonl in my java server side also as u said, can we use htonl in java, I don't know about it.
the main thing which i can see is that whether our java server side while sending integers send in which format, becoz java is platfrom independent,
i just wanna tell when i used both server and client as java still also thet data received was in same format, so i don't know whether its problem with C++ or java side, or is there something which i didn't took into account while sending
August 26th, 2003, 06:23 AM
sorry for both java side , when both are java sides, ie both client and server are java, the integers are seding normally without reversing the bytes, only when the server is java and client is C++ that byte is reversed and we don't receive normal int in the c++ side
August 26th, 2003, 06:29 AM
CAn you please tell which part of code do i have to use this ntohl(), i am trying to use it on the c++ client side but the connection gets reset and transfer is is stopped. The server send int but the client didn't received it and coneection reset: it says.
August 26th, 2003, 08:37 AM
Hey someone plz help me out
August 26th, 2003, 08:48 AM
I'm tellin you, man, send the data as ASCII characters. Debugging is orders of magnitude easier and the performance hit is probably not that great.
August 26th, 2003, 12:02 PM
doing what mitakeet said would probably be the best solution for you. if not, then...
stop sending bytes. doing this makes little to no sense to me, but perhaps someone else could shed some light as to why it does. here is why i think it doesnt:
you are transmitting 41 byte packets, 40 headers + 1 data. all of these tiny packets are going to actually slow down your sending/recieving. You should do some googling on the Nagle algorithm to learn more about this. basically it assures that small bits of data wont be sent out when there is outstanding unacknowledged data. so the longer the RTT to your target, the more delay will occur. at a bare minimum i would send out whole integers. you mentioned whether or not java has htonl(), i have no idea. i would guess that since java is platform independent there HAS to be some means of doing htonl(). if there's not, you can do some bitwise math ops to achieve the same result. what you have to do is put every single int that is sent out into NEtwork byte order. when you recieve this int on the client side, call ntohl(). if you follow those steps you shouldnt have any problems. only other thing i can think of is if you have one machine that is on a 64 bit platform. then you will have some troubles and i have no idea how to fix them. in that case, just go ASCII.
August 26th, 2003, 02:18 PM
OK, I think we solved the problems. Java's stream interfaces handle the byte order for us, so Java network programs appear to be guaranteed to output network byte order unless we mess them up. Max was having the client tell the Java server whether to output the numbers in reverse order; I advised strongly against -- IMHO, the server must ALWAYS send in network byte order.
All of the byte order compensation should go in the client. And it turned out to be a simple oversight, an uninitialized variable, that was causing the problems there.
But the main lesson learned here was that Java handles byte order for us.
August 27th, 2003, 05:20 AM
Thank you very much to all of you, dwise, infamous11, mitakeet. for providing all the information. It was very informatik for me and learned good things.
Thanks for helping me out.