Can you tell me what is the maximum size of data I can send using the stream write in the ap2ap api.

[quote=jccodez]Can you tell me what is the maximum size of data I can send using the stream write in the ap2ap api.[/quote]

I would like to know this as well. The documentation says:

"The maximum amount of write to a stream can be 0xFFFF bytes long"

But, does that mean a single WRITE command is limited to 0xFFFF bytes, and multiple WRITES can be issued for a single stream to send very large amounts of data (megabytes+)? Or does it mean that the total amount of data that can be sent to a stream overall is a max 0xFFFF bytes, and sending more data would require using multiple streams?

Hi there,

The current stream block size is 16KB after base64 encoding.

So it means more or less 12 KB raw data per block.

Regards,

Antoine

[quote=bertouta]The current stream block size is 16KB after base64 encoding.

So it means more or less 12 KB raw data per block.[/quote]

That might answer jccodez's question, but that doesn't answer mine.

Is it possible to send large files (upwards of multiple megabytes) using a single ap2ap stream with multiple WRITE commands? For example, if I have a data block that is 120 KB in size, can I issue 10 WRITE commands on a single stream to send all of the data? And be able to get 10 RECEIVED notifications on the other end, issuing 10 READ commands to receive all of the data?

If Skype is already base64-encoding the data for transmission (and why should it during the actual sending? Where does the base64 actual come into play?), then why does Skype not allow character 0x00 in the WRITE command? At least under Windows, Skype commands have a length value to let Skype know the total length of the command, so why should it matter what the contents are? Is Skype really processing commands as null-terminated strings regardless of the actual data length?

I need to be able to send binary data, including character 0x00. I've been thinking of base64-encoding the data myself when sending the WRITE command. Is there anyway to tell Skype that the data is already encoded and does not need to be encoded again?

dude, I guess you do not want to clog the channel :-) may mess up voice ect.... I think what I will do is write a service of my own that does the transfer of streams, and still use the skype contacts ect for communicating with skype users when they want to send something.... I appreciate the reply.

yes you can split your large datablock into smaller chunks and send them one by one. the receiving side will be responsible for reassembling the large block.

[quote=ppmotskula]yes you can split your large datablock into smaller chunks and send them one by one. the receiving side will be responsible for reassembling the large block.[/quote]

Thank you That is good to know.

I do have another problem, though. I am using v2.5.0.113. At the end of a transfer, I send a FINSIHED string to the recipient to let him know that the transfer is done. In other words, using Ap2Ap I do the following:

(send) ALTER APPLICATION xyz WRITE user1:id REQUEST SIZE 12345
(wait for events)
(receive) APPLICATION xyz RECEIVED user1:id
(send) ALTER APPLICATION xyz READ user1:id
(wait for events)
(received) ALTER APPLICATION xyz READ user1:id SEND
(then the following)
(send) ALTER APPLICATION xyz WRITE user1:id DATA xxxxx
(wait for events)
... repeat as needed ...
(finally)
(send) ALTER APPLICATION xyz WRITE user1:id FINISHED
(send) ALTER APPLICATION xyz DISCONNECT user1:id

The recipient never sees the RECEIVED notification for the FINISHED string, and so cannot READ it. It receives the STREAMS notification instead indicating that the stream has been closed.

It seems like Skype is not queuing the DISCONNECT and will close the connection immediately instead, even though there is still data waiting to sent. Or do I need to wait for the SENDING notification before then sending the DISCONNECT command?

Can you please address this?

can you please post bug reports into jira ( https://developer.skype.com/jira ) so that we could properly track them?

Encode Bytes to Base 64 String

The smallest String maybe sent before the larger blocks are sent.

Eg "Finished" may arrive at the client before "A Large 10K Base 64 Block - Big Long String"

From the sender:
Send how many blocks will be sent
Send a Order number with the string eg Block1, Block2, Block3 etc

On the Client:
Put each block received into an array (you could update a progress bar at this point eg Received 4 of 32)
When Number of Blocks Received = Number of Blocks sent then add all the Blocks together then Decode Base64 String to Bytes

You can also Create An Array of Apps and Streams
SKYPE4COMLib.Application
SKYPE4COMLib.ApplicationStream

Only one Stream to one App

When SkypeApp(I).Connect command is issued this in turn calls the Skype_ApplicationStreams event where the Stream is Associated with the App

Hope this helps - All the best

Woolly made a good point. The small packet indeed could arrive before the large packets.

Howerver, I think the problem gambit47_ raised is still valid because from my experience, if DISCONNECT is called before the packet is sent out, as in this case:

(send) ALTER APPLICATION xyz WRITE user1:id FINISHED
(send) ALTER APPLICATION xyz DISCONNECT user1:id

before "FINISHED" is actually sent out on the wire, the stream is closed. My guess is that the send buffer is cleared when the stream is disconnected.

I've actually filed a feature request, although I think it's really a bug:
https://developer.skype.com/jira/browse/SPA-327