File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

getreceivebuffersize or how to read the buffer size used with the send command

 
eileen keeney
Ranch Hand
Posts: 51
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



So I believe, that the socket I am trying to read from (which is written in C) is sending me the size of the message in the buffer size.

like this:

send(sock, buff, buffsize, 0)

(I have what might be the source code, but no guarantee it really is).

At one point I was counting on it using a strategy where it disconnected after each message, so I could detect the end of the message using the end of stream.
Then I discovered that it must have the read inside the while loop, and the accept, outside the while loop (the symptom was that it was reading a bunch of null messages when my side disconnected).
At that point, I was hoping to find a null terminator at the end of each message (C does use this at the end of a string).
No such luck.

So
Messages are not all the same length.
No null terminator, No carriage return, no consistent character at the end of each message.
No end of stream indication.

So How can the listener (the server) that is reading the message, know when the message ends?

The buffer size that is passed with the read command?

Does anyone have an example, that users getreceivebuffersize?

When would this actually do the action (the action of getting the receive buffer size).

If I have a read (which is for my input stream), it actually sits there and waits, for something to read.
If I have an accept, it sits there and waits for something to accept.

If I put a getreceivebuffersize, between the read and the accept, will it sit there and wait for something to getreceivebuffersize on?

(Yea I know, I can test this, and I am about to do that, but at this point, I can't even find an example, of its use. But I do have the basic specification for it, on the java.sun webpage, so might be able to figure it out.
 
Joe Ess
Bartender
Posts: 9214
9
Linux Mac OS X Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You keep mentioning "accept". Are you trying to use java.net.ServerSocket? ServerSocket binds to a port and expects other applications to attach to it. If you are writing a client, you want to use java.net.Socket
It sounds what you are struggling with is the protocol for your server and client. We really can't tell you how your server operates. I would expect it to be documented somewhere. Where did you get this server? Are you trying to write a new client or replace an existing system with a new one?
In your previous post you sounded like you were replacing the existing server with "clean java socket code". Have you given up on replacing the server, or are you trying to reverse-engineer it?
 
eileen keeney
Ranch Hand
Posts: 51
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Replacing the server was not an option for me (however it is scheduled for next year, to either replace or turn off).

Anyway I got it to work.
All evidence suggests it was detecting the message end via a time lapse between messages (sloppy, but it explained the history of failures).

It was also expecting me to do something similar on my end.

I instead opted for pulling old messages out of logs, until I figured out the lengths of the expected message types, and coded it that way. So far testing is showing this strategy to work for me.
I don't need it to never fail.

Anyway, I appreciate all the help I got on this site, and in another networking forum I ran across.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic