0

This is the situation:

I'm working on a project where I need to be able to send one or more images once in a while to/from the server as well as a lot of other types of data represented with text. The way it is currently done, is by sending a message with that says "incoming image of size x to be used as y" (It's not "formulated" that way of course), and then I call a method that reads the next x bytes through a DataInputStream. At first I met some problems with latency screwing things up, but I made the server spawn a new thread to send the "incoming image" message, and then wait for a flag that is set when the client responds with a "I'm ready for the image" message. It works in a way now, but if anything else, for instance a chat message, is sent while the image is being transfered, that message meant for a BufferedReader will be read as raw bytes and used as part of the image. So I will have to block all outgoing data (and add it to a queue) when there is an image that is being sent. But this seems very wrong and annoying, as users of the application will not be able to chat while receiving/ uploading a big image.

This is what I need: So, I either need to set up an independent channel to use for raw data. Which, as far as I understand from some tinkering, I will have to set up a new socket over a new port, which seems unnecessary. The other way I can see to solve this, would be to somehow use tag each packet with a "this is text/raw data" bit, but I have no idea how to do this with java? Can you add information to the packet-header when you write something to the stream (that every packet containing that info will contain) and then read the packet data on the other end and act accordingly?

As you can see, I do not have much experienced with networking, nor have I used Java for a long time. This is also my first post here, so be kind. If anything was unclear, please ask, and I'll specify. All ideas are welcome! (There is possibly a standard way to do this?)

Thanks a lot!

Andreas Løve Selvik
  • 1,231
  • 16
  • 25

2 Answers2

3

There is nothing in TCP protocol itself that can help you. You either open a new socket connection (can be to the same server port), or you split your images in, smaller chunks and wrap these chunks in envelopes saying what type of message it is: image or chat. And then reconstruct the image on the receiving end from these chunks. But this will waste bandwidth and add complexities of its own (e.g. how big do you make a chunk of that image?).
I would go with the separate binary data connection.

MK.
  • 31,408
  • 15
  • 67
  • 104
  • Ok, thanks a lot :) I will watch this question for a while, and probably go for a separate data connection? *Looking up how to set up multiple connections on the same port* – Andreas Løve Selvik Dec 22 '10 at 21:45
  • You just open the 2nd connection same as the first one. Server side can accept on a server socket in a loop. – MK. Dec 23 '10 at 00:25
  • Yeah, I got it to work :) Thanks again. I'll still have to use some time to make it all work, but I can see how I'm going to do it now. – Andreas Løve Selvik Dec 23 '10 at 02:36
2

Java should have a standard support for HTTP protocol - use HTTP to do your picture transfers as you can set the type of data being transmitted in the header. Basically, you would have your client/server architecture establish a separate request for each new data transfer (be it text or image), that way enabling you to do processing in a simple loop.

This might be of some help to you : How to use java.net.URLConnection to fire and handle HTTP requests?

Community
  • 1
  • 1
Jas
  • 1,111
  • 5
  • 16
  • Thanks, I'll look into it. Do you suggest that I change my whole architecture to HTTP protocol, from TCP? As far as I understand, that would make it possible to make it a web applet as well? – Andreas Løve Selvik Dec 22 '10 at 21:53
  • You don't change to HTTP from TCP because HTTP runs ON TOP of TCP (it's an application level protocol). It has nothing to do with your app being a "web applet", you can have a desktop app acting as a http client - one of these actually is your browser. And web applets are pretty much a thing of ancient past. I don't know anyone today who is seriously working on web applets anymore. – Jas Dec 22 '10 at 22:07
  • Yeah, I am aware of how it works :) But from the programmers perspective (me) I would have to change the code to send it over HTTP, even though it is still technically TCP. And I also know that it will still work as a desktop application, but I was thinking that it could be nice to have an applet version of the client, but since I was using sockets, it wasn't possible. I haven't really looked into it, but it sounds like what you suggest is the same way you make applets communicate to your server? Anyway, that's not my main concern, would just be sweet to have the option. Thanks a lot. – Andreas Løve Selvik Dec 22 '10 at 23:36
  • HTTP is not a bad idea, but will have to worry about authentication. – MK. Dec 23 '10 at 00:25