| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> if you just need the general idea or ask a concrete question
<1> since I'd like to get the data as 2-byte strings this causes problems
<1> I pretty much need to send a lot of japanese text, so I could use the writeUTF() function
<0> why do you need readLine anyway ?
<1> but that would result in about 3 bytes per character, so using 2 bytes per char would be better
<1> well, that's kind of why I'm here
<1> I thought up a solution but I'm not sure from an efficiency point of view
<0> if you read/write objects the encoding should be transparent/not matter i believe
<1> how do I write an object?
<0> writeObject
<0> or or something
<1> hmmm, brb, gonna check the api docs
<1> no, doesn't seem like it :(
<1> my solution is to use a while loop with a call to readChar() until it hits a newline character... but I have a few concerns about doing that
<1> 1) what happens if the next character arrives and we didn't call readChar() yet?
<1> 2) would it be less efficient than using readLine() ***uming it wasn't depreciated cause it doesn't work
<0> DarkJedi2 : http://java.sun.com/j2se/1.5.0/docs/api/java/io/ObjectOutputStream.html
<0> DataInput/Output is more low level and can't do it directly
<1> I see, so I could use that with a string
<0> but in general i don't get the readLine part - do you want read until carriage return and skip that ?
<1> yeah, pretty much
<0> yes of you read the object and the send data was false/doesn't match it throws an exception i believe
<1> cool
<0> but as long as you write proper objects into the stream on the other side you should be fine
<1> just coming back to my previous solution, do you know the answer to 1?
<1> that's something I wouldn't mind knowing
<1> well, I'd only be writing and receiving strings
<0> DarkJedi2 : i think the character stays in a buffer
<1> can anyone confirm that?
<0> you could test it but i think there needs to be an internal buffering mechanism for technical reasons
<1> hmmm
<0> however if you keep send without consuming (reading) you will overwrite that buffer and lose data at some point
<1> indeed
<1> anyways, thanks a million
<2> readline requires a one char lookahead, because it transparently accepts \r, \n, and \r\n as linebreaks.
<1> that was really helpful
<1> I don't get the readline statement, I get what you mean, but is that why it got depreciated?
<1> my while-loop method still has the advantage that I wouldn't be sending additional information about the object... like I said though, not really sure about the efficiency
<2> "deprecated"
<1> true
<1> sorry
<2> i was only commenting about the BufferedReader readline method.
<1> I see
<1> I wonder how readline works... for all I know it works with a while loop as well : )
<0> why not ?
<1> well, it just sounds like a kind of dodgie solution
<0> there's no effeciency issue here i believe
<0> DarkJedi2 : why dodgy ?
<1> even if 500 people are connected to you?
<0> DarkJedi2 : that is handled by other means
<1> what is/
<0> you either multithread or use java.nio
<1> oh yeah, I know, I meant all those while loops :)
<0> so the while loop is not blocking anything
<0> ?
<1> as in, I'd have like 500 threads each getting characters in a while loop
<0> so ?
<0> i mean what other structure than a loop would you use ?
<1> not a problem you don't think?
<0> no i don't see a problem
<1> cool
<0> the there'a potential overload problem
<1> ?
<0> well you cannot handle indefinitely many requests
<1> I just hope I don't run into the same problem that caused problems for readLine()... supposedly it didn't correctly re***emble the string at the other end : /
<0> but that problem you will have in any case
<0> and for high performance IO look at java.nio
<2> DarkJedi2: someone has to decide what is a linebreak/line somewhere. and you can only do that by individually looking at each byte.
<0> that should help you to avoid to many threads
<1> This method does not properly convert bytes to characters. see DataInputStream for the details and alternatives. <--- ah, actually, this doesn't even do what I want : /
<2> so wether you use 1 thread and nio or 1000 threads does not matter, you will have to look at each byte.
<1> sorry, what I just posted was from the api docs for readLine
<1> apparently that operates on bytes anyways which doesn't help me at all :)
<1> so yeah, the best thing would probably be my dodgie while-loop
<0> DarkJedi2 : it always depends what you overall goal is
<1> ***uming the characters get buffered on the socket
<1> I guess to get my communication through as pure 2-byte character strings
<0> without knowing that you can't really say much
<0> well then just write and read strings
<1> as an object you mean?
<0> and don't bother with reading (arrays of) bytes or chars
<0> as an Object or just with writeString/ReadString
<1> using an object has the problem that I'd also be sending a lot of useless data in the same go
<1> there is no writeString as far as I can tell : (
<1> there is a writeChars that can send a string... but there's no readChars
<0> yes i saw readUTF is just creating the string afterwards and not reading one
<1> indeed, though I am still considering using it
<1> though it uses a modified version of utf-8 which again doesn't really help me
<0> well if you want to minimize the bandwidth use to the absolutely required minimum, that you need to write/read bytes
<1> chars you mean
<1> but yea
<0> bytes or chars
<1> hmm
<0> however keep it mind if you send big chunks of text as strings, that the required overhead is relatively small
<0> as it occurs once per object
<1> indeed... I should perhaps consider it
<1> it is strange that there is no real readString() type function
<0> in fact ***uming no particular connection problems, you could send complete documents in one request
<0> a real readString is nothing but readObject
<0> since strings are objects and not low level simple data
<1> complete documents : /, it's possible, but it would cause quite a freeze on the client end as they wait for the document
<0> no
<0> that's what nio is for or multithreading
<1> I'm not really sure how you would do a progress indicator for something like that
<0> you have a thread handling that socket connection
<1> yeah I do
<0> so nothing freezes
<1> any idea how a progress bar could be implemented while the document is sending?
<1> receiving rather
<0> the programs works as before while the data is tranferred in the background/in parallel
<0> the java tutorial might have an example
<1> I looked at the basic tutorial but it didn't have anything like that
<0> unfortunately does swing impose some restriction on threads
<1> I think you're pretty much meant to use things like writing chars or bytes and updating the progress indicator as you go along
<0> so have a look at thread part the swing tutorial
<1> well, I know how to use threads, the problem is finding out the status of the object being sent
<0> essentially your socket thread has just to update some gui element when data comes in
<0> oh true
<1> exactly :)
<0> haven't thought of that - that i don't know without researching myself
<1> the thread essentially stops until the data is transferred
<1> in other words, perhaps it's best to work with chars
<0> a comprise would be to partition the documents in n parts and update the progress bar n times
<1> perhaps
<0> this is still not much overhead and there's no need that the progress bar indicates progress on the byte level anyway
<1> well, I could send one line at a time
<1> that way the server could use sendChars... unfortunately I'd still have to use my nasty while loop to get stuff on the server end
<1> to be quite honest it's not the client I'm worried about, but the server that would be receiving all the text from the clients connected to it
<1> well, I'll be on my way, 1:35am. I think I've got enough information now to somehow solve it
<1> another fact is that I can always change the way it functions later...
<1> if I see it becomes a problem
<1> thanks kmh, I'm off to bed
<3> hello
<3> i need some Good Coder For JAVA private me right now
<4> hello
<5> lo
<4> I'm studying Multithreading now...
<5> good
<4> It's a boring topic...wow!!!!...and kind of difficult
<4> but it's very intersting...I need to learn this very well
<5> very useful
<6> fortunatly its not that hard. The only thing which could be confusing at first is stopping/pausing a thread due to some deprecated methods.
<4> yes
<4> must get a theory about proccesses excution...states , etc...
<7> Read the book at http://www.usingcsp.com/
<7> was once of the first mathematical theories for distributed studying computation in a formal framework
<4> thanxs Asriel
<0> boring and interesting at the same time :)
<7> ah, very interesting (at least, to me :)
<8> omg i just had an awesome game idea!
<0> Paladinzz : to log off ?:-P
Return to
#java
or
Go to some related
logs:
YkYsYtO
#mysql
how to setup WUSB54G on fedora
#MissKitten
enghlish chat
#AllNiteCafe
#c
#linux
#linuxhelp
Cannot use object of type as array php strtotime
|
|